From: Mike Snitzer <hidden> Date: 2018-01-11 02:12:53
Hi Jens,
I eliminated my implementation that set disk->queue = NULL before
calling add_disk(). As we discussed it left way too much potential
for NULL pointer crashes and I agree it was too fragile.
This v3's approach is much simpler. It adjusts block core so that
blk_register_queue() can be deferred (so add_disk()'s call is avoided
if QUEUE_FLAG_DEFER_REG is set, and a driver must then call it once it
has completed initializing its request_queue).
PATCH 1 is just an unrelated fix. Christoph agreed with it in reply
to my v2 submission (but he didn't provide a Reviewed-by). Anyway,
I've revised the header to have it make more sense.
If these changes look reasonable I'd prefer that you pick them all up
for 4.16 (last DM patch included because it'll save me an awkward
dm-4.16 rebase, etc).
Thanks!
Mike
Mike Snitzer (3):
block: only bdi_unregister() in del_gendisk() if !GENHD_FL_HIDDEN
block: allow gendisk's request_queue registration to be deferred
dm: fix awkward and incomplete request_queue initialization
block/blk-sysfs.c | 4 ++++
block/genhd.c | 7 +++++--
drivers/md/dm-core.h | 2 --
drivers/md/dm-rq.c | 11 -----------
drivers/md/dm.c | 44 ++++++++++++++++++++++++++------------------
include/linux/blkdev.h | 1 +
6 files changed, 36 insertions(+), 33 deletions(-)
--
2.15.0
From: Mike Snitzer <hidden> Date: 2018-01-11 02:12:54
device_add_disk() will only call bdi_register_owner() if
!GENHD_FL_HIDDEN, so it follows that del_gendisk() should only call
bdi_unregister() if !GENHD_FL_HIDDEN.
Found with code inspection. bdi_unregister() won't do any harm if
bdi_register_owner() wasn't used but best to avoid the unnecessary
call to bdi_unregister().
Fixes: 8ddcd65325 ("block: introduce GENHD_FL_HIDDEN")
Signed-off-by: Mike Snitzer <redacted>
---
block/genhd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
On Wed, Jan 10, 2018 at 09:12:54PM -0500, Mike Snitzer wrote:
quoted hunk
device_add_disk() will only call bdi_register_owner() if
!GENHD_FL_HIDDEN, so it follows that del_gendisk() should only call
bdi_unregister() if !GENHD_FL_HIDDEN.
Found with code inspection. bdi_unregister() won't do any harm if
bdi_register_owner() wasn't used but best to avoid the unnecessary
call to bdi_unregister().
Fixes: 8ddcd65325 ("block: introduce GENHD_FL_HIDDEN")
Signed-off-by: Mike Snitzer <redacted>
---
block/genhd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
From: Hannes Reinecke <hare@suse.de> Date: 2018-01-11 07:40:25
On 01/11/2018 03:12 AM, Mike Snitzer wrote:
quoted hunk
device_add_disk() will only call bdi_register_owner() if
!GENHD_FL_HIDDEN, so it follows that del_gendisk() should only call
bdi_unregister() if !GENHD_FL_HIDDEN.
Found with code inspection. bdi_unregister() won't do any harm if
bdi_register_owner() wasn't used but best to avoid the unnecessary
call to bdi_unregister().
Fixes: 8ddcd65325 ("block: introduce GENHD_FL_HIDDEN")
Signed-off-by: Mike Snitzer <redacted>
---
block/genhd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Reviewed-by: Hannes Reinecke <hare@suse.com>
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
From: Mike Snitzer <hidden> Date: 2018-01-11 02:12:55
Since I can remember DM has forced the block layer to allow the
allocation and initialization of the request_queue to be distinct
operations. Reason for this is block/genhd.c:add_disk() has requires
that the request_queue (and associated bdi) be tied to the gendisk
before add_disk() is called -- because add_disk() also deals with
exposing the request_queue via blk_register_queue().
DM's dynamic creation of arbitrary device types (and associated
request_queue types) requires the DM device's gendisk be available so
that DM table loads can establish a master/slave relationship with
subordinate devices that are referenced by loaded DM tables -- using
bd_link_disk_holder(). But until these DM tables, and their associated
subordinate devices, are known DM cannot know what type of request_queue
it needs -- nor what its queue_limits should be.
This chicken and egg scenario has created all manner of problems for DM
and, at times, the block layer.
Summary of changes:
- Add QUEUE_FLAG_DEFER_REG that a block driver can set to defer the
required blk_register_queue() until the block driver's request_queue
is fully initialized.
- Return early from blk_unregister_queue() if QUEUE_FLAG_REGISTERED
is not set. It won't be set if a request_queue with
QUEUE_FLAG_DEFER_REG set never called blk_register_queue() -- as can
happen if a driver encounters an error and must del_gendisk() before
calling blk_register_queue().
- Export blk_register_queue().
These changes allow DM to use device_add_disk() to anchor its gendisk as
the "master" for master/slave relationships DM must establish with
subordinate devices referenced in DM tables that get loaded. Once all
"slave" devices for a DM device are known a request_queue can be
properly initialized and then advertised via sysfs -- important
improvement being that no request_queue resource initialization is
missed -- before these changes DM was known to be missing blk-mq debugfs
and proper block throttle initialization.
Signed-off-by: Mike Snitzer <redacted>
---
block/blk-sysfs.c | 4 ++++
block/genhd.c | 4 +++-
include/linux/blkdev.h | 1 +
3 files changed, 8 insertions(+), 1 deletion(-)
On Wed, Jan 10, 2018 at 09:12:55PM -0500, Mike Snitzer wrote:
quoted hunk
Since I can remember DM has forced the block layer to allow the
allocation and initialization of the request_queue to be distinct
operations. Reason for this is block/genhd.c:add_disk() has requires
that the request_queue (and associated bdi) be tied to the gendisk
before add_disk() is called -- because add_disk() also deals with
exposing the request_queue via blk_register_queue().
DM's dynamic creation of arbitrary device types (and associated
request_queue types) requires the DM device's gendisk be available so
that DM table loads can establish a master/slave relationship with
subordinate devices that are referenced by loaded DM tables -- using
bd_link_disk_holder(). But until these DM tables, and their associated
subordinate devices, are known DM cannot know what type of request_queue
it needs -- nor what its queue_limits should be.
This chicken and egg scenario has created all manner of problems for DM
and, at times, the block layer.
Summary of changes:
- Add QUEUE_FLAG_DEFER_REG that a block driver can set to defer the
required blk_register_queue() until the block driver's request_queue
is fully initialized.
- Return early from blk_unregister_queue() if QUEUE_FLAG_REGISTERED
is not set. It won't be set if a request_queue with
QUEUE_FLAG_DEFER_REG set never called blk_register_queue() -- as can
happen if a driver encounters an error and must del_gendisk() before
calling blk_register_queue().
- Export blk_register_queue().
These changes allow DM to use device_add_disk() to anchor its gendisk as
the "master" for master/slave relationships DM must establish with
subordinate devices referenced in DM tables that get loaded. Once all
"slave" devices for a DM device are known a request_queue can be
properly initialized and then advertised via sysfs -- important
improvement being that no request_queue resource initialization is
missed -- before these changes DM was known to be missing blk-mq debugfs
and proper block throttle initialization.
Signed-off-by: Mike Snitzer <redacted>
---
block/blk-sysfs.c | 4 ++++
block/genhd.c | 4 +++-
include/linux/blkdev.h | 1 +
3 files changed, 8 insertions(+), 1 deletion(-)
@@ -681,6 +681,7 @@ struct request_queue {#define QUEUE_FLAG_SCSI_PASSTHROUGH 27 /* queue supports SCSI commands */#define QUEUE_FLAG_QUIESCED 28 /* queue has been quiesced */#define QUEUE_FLAG_PREEMPT_ONLY 29 /* only process REQ_PREEMPT requests */+#define QUEUE_FLAG_DEFER_REG 30 /* defer registering queue to a disk */#define QUEUE_FLAG_DEFAULT ((1 << QUEUE_FLAG_IO_STAT) | \(1<<QUEUE_FLAG_SAME_COMP)|\
--
2.15.0
This way is safe for all other devices, even for DM it is safe too since
block does deal with NULL .make_request_fn well for legacy path.
Maybe QUEUE_FLAG_DEFER_REG can be renamed as QUEUE_FLAG_REG_BY_DRIVER,
but not a big deal, so
Reviewed-by: Ming Lei [off-list ref]
--
Ming
From: Hannes Reinecke <hare@suse.de> Date: 2018-01-11 07:46:35
On 01/11/2018 03:12 AM, Mike Snitzer wrote:
quoted hunk
Since I can remember DM has forced the block layer to allow the
allocation and initialization of the request_queue to be distinct
operations. Reason for this is block/genhd.c:add_disk() has requires
that the request_queue (and associated bdi) be tied to the gendisk
before add_disk() is called -- because add_disk() also deals with
exposing the request_queue via blk_register_queue().
DM's dynamic creation of arbitrary device types (and associated
request_queue types) requires the DM device's gendisk be available so
that DM table loads can establish a master/slave relationship with
subordinate devices that are referenced by loaded DM tables -- using
bd_link_disk_holder(). But until these DM tables, and their associated
subordinate devices, are known DM cannot know what type of request_queue
it needs -- nor what its queue_limits should be.
This chicken and egg scenario has created all manner of problems for DM
and, at times, the block layer.
Summary of changes:
- Add QUEUE_FLAG_DEFER_REG that a block driver can set to defer the
required blk_register_queue() until the block driver's request_queue
is fully initialized.
- Return early from blk_unregister_queue() if QUEUE_FLAG_REGISTERED
is not set. It won't be set if a request_queue with
QUEUE_FLAG_DEFER_REG set never called blk_register_queue() -- as can
happen if a driver encounters an error and must del_gendisk() before
calling blk_register_queue().
- Export blk_register_queue().
These changes allow DM to use device_add_disk() to anchor its gendisk as
the "master" for master/slave relationships DM must establish with
subordinate devices referenced in DM tables that get loaded. Once all
"slave" devices for a DM device are known a request_queue can be
properly initialized and then advertised via sysfs -- important
improvement being that no request_queue resource initialization is
missed -- before these changes DM was known to be missing blk-mq debugfs
and proper block throttle initialization.
Signed-off-by: Mike Snitzer <redacted>
---
block/blk-sysfs.c | 4 ++++
block/genhd.c | 4 +++-
include/linux/blkdev.h | 1 +
3 files changed, 8 insertions(+), 1 deletion(-)
@@ -681,6 +681,7 @@ struct request_queue {#define QUEUE_FLAG_SCSI_PASSTHROUGH 27 /* queue supports SCSI commands */#define QUEUE_FLAG_QUIESCED 28 /* queue has been quiesced */#define QUEUE_FLAG_PREEMPT_ONLY 29 /* only process REQ_PREEMPT requests */+#define QUEUE_FLAG_DEFER_REG 30 /* defer registering queue to a disk */#define QUEUE_FLAG_DEFAULT ((1 << QUEUE_FLAG_IO_STAT) | \(1<<QUEUE_FLAG_SAME_COMP)|\
Where is this flag used?
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
Why can't we use test_and_clear_bit() here?
Shouldn't that relieve the need for the mutex_lock() here, too?
FYI, I looked at this and then got concerned with it enough to chat with
Mikulas (cc'd) about it, here is what he said:
11:54 <mikulas> if (!test_and_clear_bit(QUEUE_FLAG_REGISTERED, &q->queue_flags))
11:55 <mikulas> this is buggy - the operation test_and_clear_bit is atomic - but if it races with some non-atomic read-modify-write operation on q->queue_flags, then the atomic modification would be lost
11:56 <mikulas> you must use always atomic accesses on q->queue_flags or always non-atomic accesses inside a mutex
11:56 <mikulas> queue_flag_clear_unlocked uses non-atomic __clear_bit
11:57 <mikulas> other functions in include/linux/blkdev.h also use non-atomic operations - so you cannot mix them with atomic operations
So my v4, that I'll send out shortly, won't be using test_and_clear_bit()
Thanks,
Mike
From: Mike Snitzer <hidden> Date: 2018-01-11 19:20:27
On Thu, Jan 11 2018 at 12:47pm -0500,
Bart Van Assche [off-list ref] wrote:
On Thu, 2018-01-11 at 12:29 -0500, Mike Snitzer wrote:
quoted
On Thu, Jan 11 2018 at 12:18pm -0500,
Bart Van Assche [off-list ref] wrote:
quoted
On Thu, 2018-01-11 at 12:04 -0500, Mike Snitzer wrote:
quoted
So my v4, that I'll send out shortly, won't be using test_and_clear_bit()
Please use queue_flag_set(), queue_flag_clear(), queue_flag_test_and_clear() and/or
queue_flag_test_and_set() to manipulate queue flags.
Can you please expand on this? My patch is only using test_bit().
Hello Mike,
I was referring to the following code, which apparenly is existing code:
mutex_lock(&q->sysfs_lock);
queue_flag_clear_unlocked(QUEUE_FLAG_REGISTERED, q);
mutex_unlock(&q->sysfs_lock);
The above code is wrong. Other code that changes the queue flags protects
these changes with the the queue lock. The above code should be changed into
the following:
spin_lock_irq(q->queue_lock);
queue_flag_clear(QUEUE_FLAG_REGISTERED, q);
spin_unlock_irq(q->queue_lock);
The only functions from which it is safe to call queue_flag_(set|clear)_unlocked()
without holding the queue lock are blk_alloc_queue_node() and
__blk_release_queue() because for these functions it is guaranteed that no queue
flag changes can happen from another context, e.g. through a blk_set_queue_dying()
call.
Yes, I noticed the use of sysfs_lock also. I've fixed it up earlier in
my v4 patchset and build on it. I'll add your Reported-by too.
Mike
From: Mike Snitzer <hidden> Date: 2018-01-11 19:50:13
On Thu, Jan 11 2018 at 2:32pm -0500,
Bart Van Assche [off-list ref] wrote:
On Thu, 2018-01-11 at 14:20 -0500, Mike Snitzer wrote:
quoted
Yes, I noticed the use of sysfs_lock also. I've fixed it up earlier in
my v4 patchset and build on it. I'll add your Reported-by too.
Hello Mike,
There are many more inconsistencies with regard to queue flag manipulation
in the block layer core and in block drivers. I'm working on a series to
address all inconsistencies in the block layer and in the sd driver.
OK, well I needed to fix this anyway to build my changes up properly.
I think my v4 changes are ready for Jens to pick up, so you'll just have
to rebase.
I'll send out v4 shortly.
Thanks,
Mike
From: Hannes Reinecke <hare@suse.de> Date: 2018-01-11 07:56:06
On 01/11/2018 03:12 AM, Mike Snitzer wrote:
quoted hunk
Since I can remember DM has forced the block layer to allow the
allocation and initialization of the request_queue to be distinct
operations. Reason for this is block/genhd.c:add_disk() has requires
that the request_queue (and associated bdi) be tied to the gendisk
before add_disk() is called -- because add_disk() also deals with
exposing the request_queue via blk_register_queue().
DM's dynamic creation of arbitrary device types (and associated
request_queue types) requires the DM device's gendisk be available so
that DM table loads can establish a master/slave relationship with
subordinate devices that are referenced by loaded DM tables -- using
bd_link_disk_holder(). But until these DM tables, and their associated
subordinate devices, are known DM cannot know what type of request_queue
it needs -- nor what its queue_limits should be.
This chicken and egg scenario has created all manner of problems for DM
and, at times, the block layer.
Summary of changes:
- Add QUEUE_FLAG_DEFER_REG that a block driver can set to defer the
required blk_register_queue() until the block driver's request_queue
is fully initialized.
- Return early from blk_unregister_queue() if QUEUE_FLAG_REGISTERED
is not set. It won't be set if a request_queue with
QUEUE_FLAG_DEFER_REG set never called blk_register_queue() -- as can
happen if a driver encounters an error and must del_gendisk() before
calling blk_register_queue().
- Export blk_register_queue().
These changes allow DM to use device_add_disk() to anchor its gendisk as
the "master" for master/slave relationships DM must establish with
subordinate devices referenced in DM tables that get loaded. Once all
"slave" devices for a DM device are known a request_queue can be
properly initialized and then advertised via sysfs -- important
improvement being that no request_queue resource initialization is
missed -- before these changes DM was known to be missing blk-mq debugfs
and proper block throttle initialization.
Signed-off-by: Mike Snitzer <redacted>
---
block/blk-sysfs.c | 4 ++++
block/genhd.c | 4 +++-
include/linux/blkdev.h | 1 +
3 files changed, 8 insertions(+), 1 deletion(-)
@@ -681,6 +681,7 @@ struct request_queue {#define QUEUE_FLAG_SCSI_PASSTHROUGH 27 /* queue supports SCSI commands */#define QUEUE_FLAG_QUIESCED 28 /* queue has been quiesced */#define QUEUE_FLAG_PREEMPT_ONLY 29 /* only process REQ_PREEMPT requests */+#define QUEUE_FLAG_DEFER_REG 30 /* defer registering queue to a disk */#define QUEUE_FLAG_DEFAULT ((1 << QUEUE_FLAG_IO_STAT) | \(1<<QUEUE_FLAG_SAME_COMP)|\
Thinking of this a bit more, wouldn't it be better to modify add_disk()
(or, rather, device_add_disk()) to handle this case?
You already moved the call to 'blk_register_queue()' to the end of
device_add_disk(), so it would be trivial to make device_add_disk() a
wrapper function like
void device_add_disk(struct device *parent, struct gendisk *disk) {
blk_add_disk(parent, disk);
blk_register_queue(disk);
}
and then call blk_add_disk() from the dm-core.
That would save us the magic 'you have to set this flag before
registering' dance in dm.c...
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
From: Mike Snitzer <hidden> Date: 2018-01-11 16:03:16
On Thu, Jan 11 2018 at 2:56am -0500,
Hannes Reinecke [off-list ref] wrote:
Thinking of this a bit more, wouldn't it be better to modify add_disk()
(or, rather, device_add_disk()) to handle this case?
You already moved the call to 'blk_register_queue()' to the end of
device_add_disk(), so it would be trivial to make device_add_disk() a
wrapper function like
void device_add_disk(struct device *parent, struct gendisk *disk) {
blk_add_disk(parent, disk);
blk_register_queue(disk);
}
and then call blk_add_disk() from the dm-core.
That would save us the magic 'you have to set this flag before
registering' dance in dm.c...
Really not seeing the QUEUE_FLAG I added as "magic", and I think it
useful to have a bit set in the queue that lets us know this variant of
queue registration was used (when debugging in "crash" or something,
avoids needing to mentally know that DM or some other driver uses it).
But if we did do what you're suggesting (see below), we're left with 2
functions that have similar names (leaving block core consumers
wondering which to use). So I think it best to rename blk_add_disk to
blk_add_disk_no_queue_reg.
I'll run with that and take a look at your other review point (should we
just use test_and_set_bit in del_gendisk). And then post v4 after
testing.
Thanks,
Mike
From: Mike Snitzer <hidden> Date: 2018-01-11 02:12:56
DM is now no longer prone to having its request_queue be improperly
initialized.
Summary of changes:
- defer DM's blk_register_queue() from add_disk()-time until
dm_setup_md_queue() by setting QUEUE_FLAG_DEFER_REG in alloc_dev().
- dm_setup_md_queue() is updated to fully initialize DM's request_queue
(_after_ all table loads have occurred and the request_queue's type,
features and limits are known).
- various other small improvements that were noticed along the way.
A very welcome side-effect of these changes is DM no longer needs to:
1) backfill the "mq" sysfs entry (because historically DM didn't
initialize the request_queue to use blk-mq until _after_
register_queue() was called via add_disk()).
2) call elv_register_queue() to get .request_fn request-based DM
device's "queue" exposed in syfs.
In addition, blk-mq debugfs support is now made available because
request-based DM's blk-mq request_queue is now properly initialized
before blk_register_queue() is called.
These changes also stave off the need to introduce new DM-specific
workarounds in block core, e.g. this proposal:
https://patchwork.kernel.org/patch/10067961/
In the end DM devices should be less unicorn in nature (relative to
initialization and availability of block core infrastructure).
Signed-off-by: Mike Snitzer <redacted>
---
drivers/md/dm-core.h | 2 --
drivers/md/dm-rq.c | 11 -----------
drivers/md/dm.c | 44 ++++++++++++++++++++++++++------------------
3 files changed, 26 insertions(+), 31 deletions(-)
On Wed, Jan 10, 2018 at 09:12:56PM -0500, Mike Snitzer wrote:
quoted hunk
DM is now no longer prone to having its request_queue be improperly
initialized.
Summary of changes:
- defer DM's blk_register_queue() from add_disk()-time until
dm_setup_md_queue() by setting QUEUE_FLAG_DEFER_REG in alloc_dev().
- dm_setup_md_queue() is updated to fully initialize DM's request_queue
(_after_ all table loads have occurred and the request_queue's type,
features and limits are known).
- various other small improvements that were noticed along the way.
A very welcome side-effect of these changes is DM no longer needs to:
1) backfill the "mq" sysfs entry (because historically DM didn't
initialize the request_queue to use blk-mq until _after_
register_queue() was called via add_disk()).
2) call elv_register_queue() to get .request_fn request-based DM
device's "queue" exposed in syfs.
In addition, blk-mq debugfs support is now made available because
request-based DM's blk-mq request_queue is now properly initialized
before blk_register_queue() is called.
These changes also stave off the need to introduce new DM-specific
workarounds in block core, e.g. this proposal:
https://patchwork.kernel.org/patch/10067961/
In the end DM devices should be less unicorn in nature (relative to
initialization and availability of block core infrastructure).
Signed-off-by: Mike Snitzer <redacted>
---
drivers/md/dm-core.h | 2 --
drivers/md/dm-rq.c | 11 -----------
drivers/md/dm.c | 44 ++++++++++++++++++++++++++------------------
3 files changed, 26 insertions(+), 31 deletions(-)
From: Hannes Reinecke <hare@suse.de> Date: 2018-01-11 07:57:40
On 01/11/2018 03:12 AM, Mike Snitzer wrote:
quoted hunk
DM is now no longer prone to having its request_queue be improperly
initialized.
Summary of changes:
- defer DM's blk_register_queue() from add_disk()-time until
dm_setup_md_queue() by setting QUEUE_FLAG_DEFER_REG in alloc_dev().
- dm_setup_md_queue() is updated to fully initialize DM's request_queue
(_after_ all table loads have occurred and the request_queue's type,
features and limits are known).
- various other small improvements that were noticed along the way.
A very welcome side-effect of these changes is DM no longer needs to:
1) backfill the "mq" sysfs entry (because historically DM didn't
initialize the request_queue to use blk-mq until _after_
register_queue() was called via add_disk()).
2) call elv_register_queue() to get .request_fn request-based DM
device's "queue" exposed in syfs.
In addition, blk-mq debugfs support is now made available because
request-based DM's blk-mq request_queue is now properly initialized
before blk_register_queue() is called.
These changes also stave off the need to introduce new DM-specific
workarounds in block core, e.g. this proposal:
https://patchwork.kernel.org/patch/10067961/
In the end DM devices should be less unicorn in nature (relative to
initialization and availability of block core infrastructure).
Signed-off-by: Mike Snitzer <redacted>
---
drivers/md/dm-core.h | 2 --
drivers/md/dm-rq.c | 11 -----------
drivers/md/dm.c | 44 ++++++++++++++++++++++++++------------------
3 files changed, 26 insertions(+), 31 deletions(-)
As mentioned in the other mail, maybe one should consider using a
wrapper function for 'add_disk()' to avoid having to set the magic queue
flag.
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)