* [PATCH v2 0/3] scsi: fixes for targets with many LUNs
@ 2023-06-06 19:38 mwilck
2023-06-06 19:38 ` [PATCH v2 1/3] bsg: increase number of devices mwilck
` (4 more replies)
0 siblings, 5 replies; 17+ messages in thread
From: mwilck @ 2023-06-06 19:38 UTC (permalink / raw)
To: Martin K. Petersen, Christoph Hellwig, Ming Lei, Bart Van Assche
Cc: James Bottomley, linux-scsi, linux-block, Hannes Reinecke, Martin Wilck
From: Martin Wilck <mwilck@suse.com>
This patch series addresses some issues we saw in a test setup
with a large number of SCSI LUNs. The first two patches simply
increase the number of available sg and bsg devices. The last one
fixes an large delay we encountered between blocking a Fibre Channel
remote port and the dev_loss_tmo.
Changes v1 -> v2:
- call blk_mq_wait_quiesce_done() from scsi_target_block() to
cover the case where BLK_MQ_F_BLOCKING is set (Bart van Assche)
Hannes Reinecke (3):
bsg: increase number of devices
scsi: sg: increase number of devices
scsi: simplify scsi_stop_queue()
block/bsg.c | 2 +-
drivers/scsi/scsi_lib.c | 28 ++++++++++++++--------------
drivers/scsi/sg.c | 2 +-
3 files changed, 16 insertions(+), 16 deletions(-)
--
2.40.1
^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH v2 1/3] bsg: increase number of devices
2023-06-06 19:38 [PATCH v2 0/3] scsi: fixes for targets with many LUNs mwilck
@ 2023-06-06 19:38 ` mwilck
2023-06-07 5:10 ` Christoph Hellwig
2023-06-06 19:38 ` [PATCH v2 2/3] scsi: sg: " mwilck
` (3 subsequent siblings)
4 siblings, 1 reply; 17+ messages in thread
From: mwilck @ 2023-06-06 19:38 UTC (permalink / raw)
To: Martin K. Petersen, Christoph Hellwig, Ming Lei, Bart Van Assche
Cc: James Bottomley, linux-scsi, linux-block, Hannes Reinecke
From: Hannes Reinecke <hare@suse.de>
Larger setups may need to allocate more than 32k bsg devices, so
increase the number of devices to the full range of minor device
numbers.
Signed-off-by: Hannes Reinecke <hare@suse.de>
---
block/bsg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/bsg.c b/block/bsg.c
index 7eca43f33d7f..c53f24243bf2 100644
--- a/block/bsg.c
+++ b/block/bsg.c
@@ -36,7 +36,7 @@ static inline struct bsg_device *to_bsg_device(struct inode *inode)
}
#define BSG_DEFAULT_CMDS 64
-#define BSG_MAX_DEVS 32768
+#define BSG_MAX_DEVS (1 << MINORBITS)
static DEFINE_IDA(bsg_minor_ida);
static struct class *bsg_class;
--
2.40.1
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH v2 2/3] scsi: sg: increase number of devices
2023-06-06 19:38 [PATCH v2 0/3] scsi: fixes for targets with many LUNs mwilck
2023-06-06 19:38 ` [PATCH v2 1/3] bsg: increase number of devices mwilck
@ 2023-06-06 19:38 ` mwilck
2023-06-07 5:10 ` Christoph Hellwig
2023-06-06 19:38 ` [PATCH v2 3/3] scsi: simplify scsi_stop_queue() mwilck
` (2 subsequent siblings)
4 siblings, 1 reply; 17+ messages in thread
From: mwilck @ 2023-06-06 19:38 UTC (permalink / raw)
To: Martin K. Petersen, Christoph Hellwig, Ming Lei, Bart Van Assche
Cc: James Bottomley, linux-scsi, linux-block, Hannes Reinecke,
Douglas Gilbert
From: Hannes Reinecke <hare@suse.de>
Larger setups may need to allocate more than 32k sg devices, so
increase the number of devices to the full range of minor device
numbers.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Acked-by: Douglas Gilbert <dgilbert@interlog.com>
---
drivers/scsi/sg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 037f8c98a6d3..6c04cf941dac 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -71,7 +71,7 @@ static int sg_proc_init(void);
#define SG_ALLOW_DIO_DEF 0
-#define SG_MAX_DEVS 32768
+#define SG_MAX_DEVS (1 << MINORBITS)
/* SG_MAX_CDB_SIZE should be 260 (spc4r37 section 3.1.30) however the type
* of sg_io_hdr::cmd_len can only represent 255. All SCSI commands greater
--
2.40.1
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH v2 3/3] scsi: simplify scsi_stop_queue()
2023-06-06 19:38 [PATCH v2 0/3] scsi: fixes for targets with many LUNs mwilck
2023-06-06 19:38 ` [PATCH v2 1/3] bsg: increase number of devices mwilck
2023-06-06 19:38 ` [PATCH v2 2/3] scsi: sg: " mwilck
@ 2023-06-06 19:38 ` mwilck
2023-06-07 5:27 ` Christoph Hellwig
2023-06-06 20:33 ` [PATCH v2 0/3] scsi: fixes for targets with many LUNs Bart Van Assche
2023-06-07 1:20 ` Ming Lei
4 siblings, 1 reply; 17+ messages in thread
From: mwilck @ 2023-06-06 19:38 UTC (permalink / raw)
To: Martin K. Petersen, Christoph Hellwig, Ming Lei, Bart Van Assche
Cc: James Bottomley, linux-scsi, linux-block, Hannes Reinecke
From: Hannes Reinecke <hare@suse.de>
scsi_target_block() calls scsi_stop_queue() for each scsi_device
and scsi_stop_queue() calls blk_mq_wait_quiesce_done() for each LUN.
As blk_mq_wait_quiesce_done() comes down to synchronize_rcu() for
SCSI queues, this can cause substantial delay for scsi_target_block()
on a target with a lot of logical units (we measured more than 100s
delay for blocking a FC rport with 2048 LUNs).
Simplify scsi_stop_queue(), which is only called in this code path, to never
wait for the quiescing to finish. Rather call blk_mq_wait_quiesce_done()
from scsi_target_block() after iterating over all devices.
Also, move the call to scsi_stop_queue() in scsi_internal_device_block()
out of the code section where the state_mutex is held.
This patch uses the same basic idea as f983622ae605 ("scsi: core: Avoid
calling synchronize_rcu() for each device in scsi_host_block()").
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Martin Wilck <mwilck@suse.com>
---
drivers/scsi/scsi_lib.c | 28 ++++++++++++++--------------
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 25489fbd94c6..bc78bea62755 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -2726,24 +2726,18 @@ void scsi_start_queue(struct scsi_device *sdev)
blk_mq_unquiesce_queue(sdev->request_queue);
}
-static void scsi_stop_queue(struct scsi_device *sdev, bool nowait)
+static void scsi_stop_queue(struct scsi_device *sdev)
{
/*
* The atomic variable of ->queue_stopped covers that
* blk_mq_quiesce_queue* is balanced with blk_mq_unquiesce_queue.
*
* However, we still need to wait until quiesce is done
- * in case that queue has been stopped.
+ * in case that queue has been stopped. This is done in
+ * scsi_target_block() for all devices of the target.
*/
- if (!cmpxchg(&sdev->queue_stopped, 0, 1)) {
- if (nowait)
- blk_mq_quiesce_queue_nowait(sdev->request_queue);
- else
- blk_mq_quiesce_queue(sdev->request_queue);
- } else {
- if (!nowait)
- blk_mq_wait_quiesce_done(sdev->request_queue->tag_set);
- }
+ if (!cmpxchg(&sdev->queue_stopped, 0, 1))
+ blk_mq_quiesce_queue_nowait(sdev->request_queue);
}
/**
@@ -2770,7 +2764,7 @@ int scsi_internal_device_block_nowait(struct scsi_device *sdev)
* request queue.
*/
if (!ret)
- scsi_stop_queue(sdev, true);
+ scsi_stop_queue(sdev);
return ret;
}
EXPORT_SYMBOL_GPL(scsi_internal_device_block_nowait);
@@ -2796,9 +2790,9 @@ static int scsi_internal_device_block(struct scsi_device *sdev)
mutex_lock(&sdev->state_mutex);
err = __scsi_internal_device_block_nowait(sdev);
- if (err == 0)
- scsi_stop_queue(sdev, false);
mutex_unlock(&sdev->state_mutex);
+ if (err == 0)
+ scsi_stop_queue(sdev);
return err;
}
@@ -2906,11 +2900,17 @@ target_block(struct device *dev, void *data)
void
scsi_target_block(struct device *dev)
{
+ struct Scsi_Host *shost = dev_to_shost(dev);
+
if (scsi_is_target_device(dev))
starget_for_each_device(to_scsi_target(dev), NULL,
device_block);
else
device_for_each_child(dev, NULL, target_block);
+
+ /* Wait for ongoing scsi_queue_rq() calls to finish. */
+ if (!WARN_ON_ONCE(!shost))
+ blk_mq_wait_quiesce_done(&shost->tag_set);
}
EXPORT_SYMBOL_GPL(scsi_target_block);
--
2.40.1
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH v2 0/3] scsi: fixes for targets with many LUNs
2023-06-06 19:38 [PATCH v2 0/3] scsi: fixes for targets with many LUNs mwilck
` (2 preceding siblings ...)
2023-06-06 19:38 ` [PATCH v2 3/3] scsi: simplify scsi_stop_queue() mwilck
@ 2023-06-06 20:33 ` Bart Van Assche
2023-06-07 1:20 ` Ming Lei
4 siblings, 0 replies; 17+ messages in thread
From: Bart Van Assche @ 2023-06-06 20:33 UTC (permalink / raw)
To: mwilck, Martin K. Petersen, Christoph Hellwig, Ming Lei, Bart Van Assche
Cc: James Bottomley, linux-scsi, linux-block, Hannes Reinecke
On 6/6/23 12:38, mwilck@suse.com wrote:
> From: Martin Wilck <mwilck@suse.com>
>
> This patch series addresses some issues we saw in a test setup
> with a large number of SCSI LUNs. The first two patches simply
> increase the number of available sg and bsg devices. The last one
> fixes an large delay we encountered between blocking a Fibre Channel
> remote port and the dev_loss_tmo.
>
> Changes v1 -> v2:
> - call blk_mq_wait_quiesce_done() from scsi_target_block() to
> cover the case where BLK_MQ_F_BLOCKING is set (Bart van Assche)
For the entire series:
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2 0/3] scsi: fixes for targets with many LUNs
2023-06-06 19:38 [PATCH v2 0/3] scsi: fixes for targets with many LUNs mwilck
` (3 preceding siblings ...)
2023-06-06 20:33 ` [PATCH v2 0/3] scsi: fixes for targets with many LUNs Bart Van Assche
@ 2023-06-07 1:20 ` Ming Lei
4 siblings, 0 replies; 17+ messages in thread
From: Ming Lei @ 2023-06-07 1:20 UTC (permalink / raw)
To: mwilck
Cc: Martin K. Petersen, Christoph Hellwig, Bart Van Assche,
James Bottomley, linux-scsi, linux-block, Hannes Reinecke
On Wed, Jun 7, 2023 at 3:38 AM <mwilck@suse.com> wrote:
>
> From: Martin Wilck <mwilck@suse.com>
>
> This patch series addresses some issues we saw in a test setup
> with a large number of SCSI LUNs. The first two patches simply
> increase the number of available sg and bsg devices. The last one
> fixes an large delay we encountered between blocking a Fibre Channel
> remote port and the dev_loss_tmo.
>
> Changes v1 -> v2:
> - call blk_mq_wait_quiesce_done() from scsi_target_block() to
> cover the case where BLK_MQ_F_BLOCKING is set (Bart van Assche)
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Thanks,
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2 1/3] bsg: increase number of devices
2023-06-06 19:38 ` [PATCH v2 1/3] bsg: increase number of devices mwilck
@ 2023-06-07 5:10 ` Christoph Hellwig
0 siblings, 0 replies; 17+ messages in thread
From: Christoph Hellwig @ 2023-06-07 5:10 UTC (permalink / raw)
To: mwilck
Cc: Martin K. Petersen, Christoph Hellwig, Ming Lei, Bart Van Assche,
James Bottomley, linux-scsi, linux-block, Hannes Reinecke
On Tue, Jun 06, 2023 at 09:38:43PM +0200, mwilck@suse.com wrote:
> From: Hannes Reinecke <hare@suse.de>
>
> Larger setups may need to allocate more than 32k bsg devices, so
> increase the number of devices to the full range of minor device
> numbers.
>
> Signed-off-by: Hannes Reinecke <hare@suse.de>
Martin, if you send this on it also needs your signoff.
Otherwise looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2 2/3] scsi: sg: increase number of devices
2023-06-06 19:38 ` [PATCH v2 2/3] scsi: sg: " mwilck
@ 2023-06-07 5:10 ` Christoph Hellwig
0 siblings, 0 replies; 17+ messages in thread
From: Christoph Hellwig @ 2023-06-07 5:10 UTC (permalink / raw)
To: mwilck
Cc: Martin K. Petersen, Christoph Hellwig, Ming Lei, Bart Van Assche,
James Bottomley, linux-scsi, linux-block, Hannes Reinecke,
Douglas Gilbert
On Tue, Jun 06, 2023 at 09:38:44PM +0200, mwilck@suse.com wrote:
> From: Hannes Reinecke <hare@suse.de>
>
> Larger setups may need to allocate more than 32k sg devices, so
> increase the number of devices to the full range of minor device
> numbers.
>
> Signed-off-by: Hannes Reinecke <hare@suse.de>
> Acked-by: Douglas Gilbert <dgilbert@interlog.com>
Same comment about the signoff.
Otherwise looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2 3/3] scsi: simplify scsi_stop_queue()
2023-06-06 19:38 ` [PATCH v2 3/3] scsi: simplify scsi_stop_queue() mwilck
@ 2023-06-07 5:27 ` Christoph Hellwig
2023-06-07 9:26 ` Martin Wilck
0 siblings, 1 reply; 17+ messages in thread
From: Christoph Hellwig @ 2023-06-07 5:27 UTC (permalink / raw)
To: mwilck
Cc: Martin K. Petersen, Christoph Hellwig, Ming Lei, Bart Van Assche,
James Bottomley, linux-scsi, linux-block, Hannes Reinecke
On Tue, Jun 06, 2023 at 09:38:45PM +0200, mwilck@suse.com wrote:
> Simplify scsi_stop_queue(), which is only called in this code path, to never
> wait for the quiescing to finish. Rather call blk_mq_wait_quiesce_done()
> from scsi_target_block() after iterating over all devices.
I don't think simplify is the right word here. The code isn't in any
way simpler, it just is more efficient an shifts work from
scsi_stop_queue to scsi_internal_device_block and scsi_target_block.
But the whole transformation is very confusing to me even if it looks
correct in the end, and it took me quite a while to understand it.
I'd suggest to further split this up and include some additional
cleanups:
1) remove scsi_internal_device_block and fold it into device_block
2) move the scsi_internal_device_block in what was
scsi_internal_device_block and now is device_block out
of state_mutex (and document in the commit log why this is safe)
3) remove scsi_stop_queue and open code it in the two callers, one
of which currently wants nowait semantics, and one that doesn't.
4) move the quiesce wait to scsi_target_block and make it per-tagset
> scsi_target_block(struct device *dev)
> {
> + struct Scsi_Host *shost = dev_to_shost(dev);
> +
> if (scsi_is_target_device(dev))
> starget_for_each_device(to_scsi_target(dev), NULL,
> device_block);
> else
> device_for_each_child(dev, NULL, target_block);
> +
> + /* Wait for ongoing scsi_queue_rq() calls to finish. */
> + if (!WARN_ON_ONCE(!shost))
How could host ever be NULL here? I can't see why we'd want this
check.
Btw, as far as I can tell scsi_target_block is never called for
a device that is a target device. It might be worth throwing in
another patch to remove support for that case and simplify things
further.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2 3/3] scsi: simplify scsi_stop_queue()
2023-06-07 5:27 ` Christoph Hellwig
@ 2023-06-07 9:26 ` Martin Wilck
2023-06-07 9:36 ` Martin Wilck
2023-06-07 14:05 ` Bart Van Assche
0 siblings, 2 replies; 17+ messages in thread
From: Martin Wilck @ 2023-06-07 9:26 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Martin K. Petersen, Ming Lei, Bart Van Assche, James Bottomley,
linux-scsi, linux-block, Hannes Reinecke
On Wed, 2023-06-07 at 07:27 +0200, Christoph Hellwig wrote:
> On Tue, Jun 06, 2023 at 09:38:45PM +0200, mwilck@suse.com wrote:
> > Simplify scsi_stop_queue(), which is only called in this code path,
> > to never
> > wait for the quiescing to finish. Rather call
> > blk_mq_wait_quiesce_done()
> > from scsi_target_block() after iterating over all devices.
>
> I don't think simplify is the right word here. The code isn't in any
> way simpler, it just is more efficient an shifts work from
> scsi_stop_queue to scsi_internal_device_block and scsi_target_block.
>
> But the whole transformation is very confusing to me even if it looks
> correct in the end, and it took me quite a while to understand it.
>
> I'd suggest to further split this up and include some additional
> cleanups:
>
> 1) remove scsi_internal_device_block and fold it into device_block
ok
> 2) move the scsi_internal_device_block in what was
You mean scsi_stop_queue() here, right?
> scsi_internal_device_block and now is device_block out
> of state_mutex (and document in the commit log why this is safe)
> 3) remove scsi_stop_queue and open code it in the two callers, one
> of which currently wants nowait semantics, and one that doesn't.
ok
> 4) move the quiesce wait to scsi_target_block and make it per-
> tagset
ok
>
> > scsi_target_block(struct device *dev)
> > {
> > + struct Scsi_Host *shost = dev_to_shost(dev);
> > +
> > if (scsi_is_target_device(dev))
> > starget_for_each_device(to_scsi_target(dev), NULL,
> > device_block);
> > else
> > device_for_each_child(dev, NULL, target_block);
> > +
> > + /* Wait for ongoing scsi_queue_rq() calls to finish. */
> > + if (!WARN_ON_ONCE(!shost))
>
> How could host ever be NULL here? I can't see why we'd want this
> check.
>
The reason is simple: I wasn't certain if dev_to_shost() could return
NULL, and preferred skipping the wait over an Oops. I hear you say that
dev_to_shost() can't go wrong, so I'll remove the NULL test.
> Btw, as far as I can tell scsi_target_block is never called for
> a device that is a target device. It might be worth throwing in
> another patch to remove support for that case and simplify things
> further.
Can we do this separately, maybe?
Thanks,
Martin
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2 3/3] scsi: simplify scsi_stop_queue()
2023-06-07 9:26 ` Martin Wilck
@ 2023-06-07 9:36 ` Martin Wilck
2023-06-07 13:34 ` Christoph Hellwig
2023-06-07 14:05 ` Bart Van Assche
1 sibling, 1 reply; 17+ messages in thread
From: Martin Wilck @ 2023-06-07 9:36 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Martin K. Petersen, Ming Lei, Bart Van Assche, James Bottomley,
linux-scsi, linux-block, Hannes Reinecke
On Wed, 2023-06-07 at 11:26 +0200, Martin Wilck wrote:
> On Wed, 2023-06-07 at 07:27 +0200, Christoph Hellwig wrote:
> >
> > 3) remove scsi_stop_queue and open code it in the two callers,
> > one
> > of which currently wants nowait semantics, and one that
> > doesn't.
> ok
Hm, scsi_stop_queue() pairs with scsi_start_queue(), do we really want
to open-code it?
Martin
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2 3/3] scsi: simplify scsi_stop_queue()
2023-06-07 9:36 ` Martin Wilck
@ 2023-06-07 13:34 ` Christoph Hellwig
0 siblings, 0 replies; 17+ messages in thread
From: Christoph Hellwig @ 2023-06-07 13:34 UTC (permalink / raw)
To: Martin Wilck
Cc: Christoph Hellwig, Martin K. Petersen, Ming Lei, Bart Van Assche,
James Bottomley, linux-scsi, linux-block, Hannes Reinecke
On Wed, Jun 07, 2023 at 11:26:04AM +0200, Martin Wilck wrote:
> > cleanups:
> >
> > 1) remove scsi_internal_device_block and fold it into device_block
>
> ok
>
> > 2) move the scsi_internal_device_block in what was
>
> You mean scsi_stop_queue() here, right?
Yes.
> The reason is simple: I wasn't certain if dev_to_shost() could return
> NULL, and preferred skipping the wait over an Oops. I hear you say that
> dev_to_shost() can't go wrong, so I'll remove the NULL test.
Well, the parent device can't really go away while we have a reference
to a child. So the only case where it can return NULL is if the
passed in device isn't the child of a SCSI host, which would be a grave
programming error.
>
> > Btw, as far as I can tell scsi_target_block is never called for
> > a device that is a target device. It might be worth throwing in
> > another patch to remove support for that case and simplify things
> > further.
>
> Can we do this separately, maybe?
Sure. Would be nice to just tack into onto the end of this series
if you touch the area, though.
> On Wed, 2023-06-07 at 11:26 +0200, Martin Wilck wrote:
> > On Wed, 2023-06-07 at 07:27 +0200, Christoph Hellwig wrote:
> > >
> > > 3) remove scsi_stop_queue and open code it in the two callers,
> > > one
> > > of which currently wants nowait semantics, and one that
> > > doesn't.
> > ok
>
> Hm, scsi_stop_queue() pairs with scsi_start_queue(), do we really want
> to open-code it?
Oh well, feel free to keep it if you prefer it that way.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2 3/3] scsi: simplify scsi_stop_queue()
2023-06-07 9:26 ` Martin Wilck
2023-06-07 9:36 ` Martin Wilck
@ 2023-06-07 14:05 ` Bart Van Assche
2023-06-07 14:08 ` Christoph Hellwig
2023-06-07 15:38 ` Martin Wilck
1 sibling, 2 replies; 17+ messages in thread
From: Bart Van Assche @ 2023-06-07 14:05 UTC (permalink / raw)
To: Martin Wilck, Christoph Hellwig
Cc: Martin K. Petersen, Ming Lei, Bart Van Assche, James Bottomley,
linux-scsi, linux-block, Hannes Reinecke
On 6/7/23 02:26, Martin Wilck wrote:
> On Wed, 2023-06-07 at 07:27 +0200, Christoph Hellwig wrote:
>> On Tue, Jun 06, 2023 at 09:38:45PM +0200, mwilck@suse.com wrote:
>>> scsi_target_block(struct device *dev)
>>> {
>>> + struct Scsi_Host *shost = dev_to_shost(dev);
>>> +
>>> if (scsi_is_target_device(dev))
>>> starget_for_each_device(to_scsi_target(dev), NULL,
>>> device_block);
>>> else
>>> device_for_each_child(dev, NULL, target_block);
>>> +
>>> + /* Wait for ongoing scsi_queue_rq() calls to finish. */
>>> + if (!WARN_ON_ONCE(!shost))
>>
>> How could host ever be NULL here? I can't see why we'd want this
>> check.
>
> The reason is simple: I wasn't certain if dev_to_shost() could return
> NULL, and preferred skipping the wait over an Oops. I hear you say that
> dev_to_shost() can't go wrong, so I'll remove the NULL test.
I propose to pass shost as the first argument to scsi_target_block()
instead of using dev_to_shost() inside scsi_target_block(). Except in
__iscsi_block_session(), shost is already available as a local variable.
Bart.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2 3/3] scsi: simplify scsi_stop_queue()
2023-06-07 14:05 ` Bart Van Assche
@ 2023-06-07 14:08 ` Christoph Hellwig
2023-06-07 15:38 ` Martin Wilck
1 sibling, 0 replies; 17+ messages in thread
From: Christoph Hellwig @ 2023-06-07 14:08 UTC (permalink / raw)
To: Bart Van Assche
Cc: Martin Wilck, Christoph Hellwig, Martin K. Petersen, Ming Lei,
Bart Van Assche, James Bottomley, linux-scsi, linux-block,
Hannes Reinecke
On Wed, Jun 07, 2023 at 07:05:34AM -0700, Bart Van Assche wrote:
>> The reason is simple: I wasn't certain if dev_to_shost() could return
>> NULL, and preferred skipping the wait over an Oops. I hear you say that
>> dev_to_shost() can't go wrong, so I'll remove the NULL test.
>
> I propose to pass shost as the first argument to scsi_target_block()
> instead of using dev_to_shost() inside scsi_target_block(). Except in
> __iscsi_block_session(), shost is already available as a local variable.
That sounds like a good idea to me.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2 3/3] scsi: simplify scsi_stop_queue()
2023-06-07 14:05 ` Bart Van Assche
2023-06-07 14:08 ` Christoph Hellwig
@ 2023-06-07 15:38 ` Martin Wilck
2023-06-07 16:39 ` Bart Van Assche
1 sibling, 1 reply; 17+ messages in thread
From: Martin Wilck @ 2023-06-07 15:38 UTC (permalink / raw)
To: Bart Van Assche, Christoph Hellwig
Cc: Martin K. Petersen, Ming Lei, Bart Van Assche, James Bottomley,
linux-scsi, linux-block, Hannes Reinecke
On Wed, 2023-06-07 at 07:05 -0700, Bart Van Assche wrote:
> On 6/7/23 02:26, Martin Wilck wrote:
> > On Wed, 2023-06-07 at 07:27 +0200, Christoph Hellwig wrote:
> > > On Tue, Jun 06, 2023 at 09:38:45PM +0200, mwilck@suse.com wrote:
> > > > scsi_target_block(struct device *dev)
> > > > {
> > > > + struct Scsi_Host *shost = dev_to_shost(dev);
> > > > +
> > > > if (scsi_is_target_device(dev))
> > > > starget_for_each_device(to_scsi_target(dev),
> > > > NULL,
> > > > device_block);
> > > > else
> > > > device_for_each_child(dev, NULL,
> > > > target_block);
> > > > +
> > > > + /* Wait for ongoing scsi_queue_rq() calls to finish. */
> > > > + if (!WARN_ON_ONCE(!shost))
> > >
> > > How could host ever be NULL here? I can't see why we'd want this
> > > check.
> >
> > The reason is simple: I wasn't certain if dev_to_shost() could
> > return
> > NULL, and preferred skipping the wait over an Oops. I hear you say
> > that
> > dev_to_shost() can't go wrong, so I'll remove the NULL test.
>
> I propose to pass shost as the first argument to scsi_target_block()
> instead of using dev_to_shost() inside scsi_target_block(). Except in
> __iscsi_block_session(), shost is already available as a local
> variable.
If we do this, it might actually be cleaner to just pass the tag set to
wait for.
Martin
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2 3/3] scsi: simplify scsi_stop_queue()
2023-06-07 15:38 ` Martin Wilck
@ 2023-06-07 16:39 ` Bart Van Assche
2023-06-07 17:56 ` Martin Wilck
0 siblings, 1 reply; 17+ messages in thread
From: Bart Van Assche @ 2023-06-07 16:39 UTC (permalink / raw)
To: Martin Wilck, Christoph Hellwig
Cc: Martin K. Petersen, Ming Lei, Bart Van Assche, James Bottomley,
linux-scsi, linux-block, Hannes Reinecke
On 6/7/23 08:38, Martin Wilck wrote:
> On Wed, 2023-06-07 at 07:05 -0700, Bart Van Assche wrote:
>> On 6/7/23 02:26, Martin Wilck wrote:
>>> On Wed, 2023-06-07 at 07:27 +0200, Christoph Hellwig wrote:
>>>> On Tue, Jun 06, 2023 at 09:38:45PM +0200, mwilck@suse.com wrote:
>>>>> scsi_target_block(struct device *dev)
>>>>> {
>>>>> + struct Scsi_Host *shost = dev_to_shost(dev);
>>>>> +
>>>>> if (scsi_is_target_device(dev))
>>>>> starget_for_each_device(to_scsi_target(dev),
>>>>> NULL,
>>>>> device_block);
>>>>> else
>>>>> device_for_each_child(dev, NULL,
>>>>> target_block);
>>>>> +
>>>>> + /* Wait for ongoing scsi_queue_rq() calls to finish. */
>>>>> + if (!WARN_ON_ONCE(!shost))
>>>>
>>>> How could host ever be NULL here? I can't see why we'd want this
>>>> check.
>>>
>>> The reason is simple: I wasn't certain if dev_to_shost() could
>>> return
>>> NULL, and preferred skipping the wait over an Oops. I hear you say
>>> that
>>> dev_to_shost() can't go wrong, so I'll remove the NULL test.
>>
>> I propose to pass shost as the first argument to scsi_target_block()
>> instead of using dev_to_shost() inside scsi_target_block(). Except in
>> __iscsi_block_session(), shost is already available as a local
>> variable.
>
> If we do this, it might actually be cleaner to just pass the tag set to
> wait for.
Wouldn't that be close to a layering violation? Shouldn't SCSI APIs accept
pointers to SCSI objects instead of pointers to block layer abstractions?
Thanks,
Bart.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2 3/3] scsi: simplify scsi_stop_queue()
2023-06-07 16:39 ` Bart Van Assche
@ 2023-06-07 17:56 ` Martin Wilck
0 siblings, 0 replies; 17+ messages in thread
From: Martin Wilck @ 2023-06-07 17:56 UTC (permalink / raw)
To: Bart Van Assche, Christoph Hellwig
Cc: Martin K. Petersen, Ming Lei, Bart Van Assche, James Bottomley,
linux-scsi, linux-block, Hannes Reinecke
On Wed, 2023-06-07 at 09:39 -0700, Bart Van Assche wrote:
> On 6/7/23 08:38, Martin Wilck wrote:
> > On Wed, 2023-06-07 at 07:05 -0700, Bart Van Assche wrote:
> > > On 6/7/23 02:26, Martin Wilck wrote:
> > > > On Wed, 2023-06-07 at 07:27 +0200, Christoph Hellwig wrote:
> > > > > On Tue, Jun 06, 2023 at 09:38:45PM +0200,
> > > > > mwilck@suse.com wrote:
> > > > > > scsi_target_block(struct device *dev)
> > > > > > {
> > > > > > + struct Scsi_Host *shost = dev_to_shost(dev);
> > > > > > +
> > > > > > if (scsi_is_target_device(dev))
> > > > > > starget_for_each_device(to_scsi_target(de
> > > > > > v),
> > > > > > NULL,
> > > > > > device_block);
> > > > > > else
> > > > > > device_for_each_child(dev, NULL,
> > > > > > target_block);
> > > > > > +
> > > > > > + /* Wait for ongoing scsi_queue_rq() calls to
> > > > > > finish. */
> > > > > > + if (!WARN_ON_ONCE(!shost))
> > > > >
> > > > > How could host ever be NULL here? I can't see why we'd want
> > > > > this
> > > > > check.
> > > >
> > > > The reason is simple: I wasn't certain if dev_to_shost() could
> > > > return
> > > > NULL, and preferred skipping the wait over an Oops. I hear you
> > > > say
> > > > that
> > > > dev_to_shost() can't go wrong, so I'll remove the NULL test.
> > >
> > > I propose to pass shost as the first argument to
> > > scsi_target_block()
> > > instead of using dev_to_shost() inside scsi_target_block().
> > > Except in
> > > __iscsi_block_session(), shost is already available as a local
> > > variable.
> >
> > If we do this, it might actually be cleaner to just pass the tag
> > set to
> > wait for.
>
> Wouldn't that be close to a layering violation? Shouldn't SCSI APIs
> accept
> pointers to SCSI objects instead of pointers to block layer
> abstractions?
My thought was that quiescing is based on tag sets in current kernels,
and passing in the tag set to scsi_target_block() would make that
explicit.
But you've got a point. I'll resubmit the with a Scsi_Host argument and
see how it goes.
Thanks,
Martin
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2023-06-07 17:56 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-06-06 19:38 [PATCH v2 0/3] scsi: fixes for targets with many LUNs mwilck
2023-06-06 19:38 ` [PATCH v2 1/3] bsg: increase number of devices mwilck
2023-06-07 5:10 ` Christoph Hellwig
2023-06-06 19:38 ` [PATCH v2 2/3] scsi: sg: " mwilck
2023-06-07 5:10 ` Christoph Hellwig
2023-06-06 19:38 ` [PATCH v2 3/3] scsi: simplify scsi_stop_queue() mwilck
2023-06-07 5:27 ` Christoph Hellwig
2023-06-07 9:26 ` Martin Wilck
2023-06-07 9:36 ` Martin Wilck
2023-06-07 13:34 ` Christoph Hellwig
2023-06-07 14:05 ` Bart Van Assche
2023-06-07 14:08 ` Christoph Hellwig
2023-06-07 15:38 ` Martin Wilck
2023-06-07 16:39 ` Bart Van Assche
2023-06-07 17:56 ` Martin Wilck
2023-06-06 20:33 ` [PATCH v2 0/3] scsi: fixes for targets with many LUNs Bart Van Assche
2023-06-07 1:20 ` Ming Lei
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.