[PATCH] scsi: core: Fix a regression triggered by scsi_host_busy()

[PATCH] scsi: core: Fix a regression triggered by scsi_host_busy()

[Bart Van Assche]

Commit 995412e23bb2 ("blk-mq: Replace tags->lock with SRCU for tag
iterators") introduced the following regression:

Call trace:
 __srcu_read_lock+0x30/0x80 (P)
 blk_mq_tagset_busy_iter+0x44/0x300
 scsi_host_busy+0x38/0x70
 ufshcd_print_host_state+0x34/0x1bc
 ufshcd_link_startup.constprop.0+0xe4/0x2e0
 ufshcd_init+0x944/0xf80
 ufshcd_pltfrm_init+0x504/0x820
 ufs_rockchip_probe+0x2c/0x88
 platform_probe+0x5c/0xa4
 really_probe+0xc0/0x38c
 __driver_probe_device+0x7c/0x150
 driver_probe_device+0x40/0x120
 __driver_attach+0xc8/0x1e0
 bus_for_each_dev+0x7c/0xdc
 driver_attach+0x24/0x30
 bus_add_driver+0x110/0x230
 driver_register+0x68/0x130
 __platform_driver_register+0x20/0x2c
 ufs_rockchip_pltform_init+0x1c/0x28
 do_one_initcall+0x60/0x1e0
 kernel_init_freeable+0x248/0x2c4
 kernel_init+0x20/0x140
 ret_from_fork+0x10/0x20

Fix this regression by making scsi_host_busy() check whether the SCSI
host tag set has already been initialized. tag_set->ops is set by
scsi_mq_setup_tags() just before blk_mq_alloc_tag_set() is called. This
fix is based on the assumption that scsi_host_busy() and
scsi_mq_setup_tags() calls are serialized. This is the case in the UFS
driver.

Reported-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Closes: https://lore.kernel.org/linux-block/pnezafputodmqlpumwfbn644ohjybouveehcjhz2hmhtcf2rka@sdhoiivync4y/
Cc: Ming Lei <ming.lei@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
 drivers/scsi/hosts.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
index cc5d05dc395c..17173239301e 100644
--- a/drivers/scsi/hosts.c
+++ b/drivers/scsi/hosts.c
@@ -611,8 +611,9 @@ int scsi_host_busy(struct Scsi_Host *shost)
 {
 	int cnt = 0;
 
-	blk_mq_tagset_busy_iter(&shost->tag_set,
-				scsi_host_check_in_flight, &cnt);
+	if (shost->tag_set.ops)
+		blk_mq_tagset_busy_iter(&shost->tag_set,
+					scsi_host_check_in_flight, &cnt);
 	return cnt;
 }
 EXPORT_SYMBOL(scsi_host_busy);

Re: [PATCH] scsi: core: Fix a regression triggered by scsi_host_busy()

[Ming Lei]

On Wed, Oct 8, 2025 at 5:48 AM Bart Van Assche <bvanassche@acm.org> wrote:
>
> Commit 995412e23bb2 ("blk-mq: Replace tags->lock with SRCU for tag
> iterators") introduced the following regression:
>
> Call trace:
>  __srcu_read_lock+0x30/0x80 (P)
>  blk_mq_tagset_busy_iter+0x44/0x300
>  scsi_host_busy+0x38/0x70
>  ufshcd_print_host_state+0x34/0x1bc
>  ufshcd_link_startup.constprop.0+0xe4/0x2e0
>  ufshcd_init+0x944/0xf80
>  ufshcd_pltfrm_init+0x504/0x820
>  ufs_rockchip_probe+0x2c/0x88
>  platform_probe+0x5c/0xa4
>  really_probe+0xc0/0x38c
>  __driver_probe_device+0x7c/0x150
>  driver_probe_device+0x40/0x120
>  __driver_attach+0xc8/0x1e0
>  bus_for_each_dev+0x7c/0xdc
>  driver_attach+0x24/0x30
>  bus_add_driver+0x110/0x230
>  driver_register+0x68/0x130
>  __platform_driver_register+0x20/0x2c
>  ufs_rockchip_pltform_init+0x1c/0x28
>  do_one_initcall+0x60/0x1e0
>  kernel_init_freeable+0x248/0x2c4
>  kernel_init+0x20/0x140
>  ret_from_fork+0x10/0x20
>
> Fix this regression by making scsi_host_busy() check whether the SCSI
> host tag set has already been initialized. tag_set->ops is set by
> scsi_mq_setup_tags() just before blk_mq_alloc_tag_set() is called. This
> fix is based on the assumption that scsi_host_busy() and
> scsi_mq_setup_tags() calls are serialized. This is the case in the UFS
> driver.
>
> Reported-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> Closes: https://lore.kernel.org/linux-block/pnezafputodmqlpumwfbn644ohjybouveehcjhz2hmhtcf2rka@sdhoiivync4y/
> Cc: Ming Lei <ming.lei@redhat.com>
> Cc: Jens Axboe <axboe@kernel.dk>
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
> ---
>  drivers/scsi/hosts.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
> index cc5d05dc395c..17173239301e 100644
> --- a/drivers/scsi/hosts.c
> +++ b/drivers/scsi/hosts.c
> @@ -611,8 +611,9 @@ int scsi_host_busy(struct Scsi_Host *shost)
>  {
>         int cnt = 0;
>
> -       blk_mq_tagset_busy_iter(&shost->tag_set,
> -                               scsi_host_check_in_flight, &cnt);
> +       if (shost->tag_set.ops)
> +               blk_mq_tagset_busy_iter(&shost->tag_set,
> +                                       scsi_host_check_in_flight, &cnt);
>         return cnt;
>  }
>  EXPORT_SYMBOL(scsi_host_busy);

Reviewed-by: Ming Lei <ming.lei@redhat.com>

Long term, the UFS driver need to be fixed, this or most of scsi core
APIs should
have been called after the scsi host is initialized.

Thanks,
Ming

Re: [PATCH] scsi: core: Fix a regression triggered by scsi_host_busy()

[Christoph Hellwig]

On Wed, Oct 08, 2025 at 11:17:18AM +0800, Ming Lei wrote:
> Long term, the UFS driver need to be fixed, this or most of scsi core
> APIs should
> have been called after the scsi host is initialized.

Please fix ufs now.  Otherwise we'll be stuck with these hacks forever
as they never get cleaned up.

Re: [PATCH] scsi: core: Fix a regression triggered by scsi_host_busy()

[Sebastian Reichel]

Hi,

On Tue, Oct 07, 2025 at 10:50:10PM -0700, Christoph Hellwig wrote:
> On Wed, Oct 08, 2025 at 11:17:18AM +0800, Ming Lei wrote:
> > Long term, the UFS driver need to be fixed, this or most of scsi core
> > APIs should
> > have been called after the scsi host is initialized.
> 
> Please fix ufs now.  Otherwise we'll be stuck with these hacks forever
> as they never get cleaned up.

The Rock 4D has a pluggable UFS module. UFS is described in the
system's device-tree, but the affected system itself does not
have a module plugged in resulting in UFS erroring out early.

To have an idea - the following is logged at error level because
no UFS module is plugged:

[    2.731721] ufshcd-rockchip 2a2d0000.ufshc: link startup failed 1
[    2.732311] ufshcd-rockchip 2a2d0000.ufshc: UFS Host state=0
[    2.732812] ufshcd-rockchip 2a2d0000.ufshc: 0 outstanding reqs, tasks=0x0
[    2.733410] ufshcd-rockchip 2a2d0000.ufshc: saved_err=0x0, saved_uic_err=0x0
[    2.734030] ufshcd-rockchip 2a2d0000.ufshc: Device power mode=1, UIC link state=0
[    2.734687] ufshcd-rockchip 2a2d0000.ufshc: PM in progress=0, sys. suspended=0
[    2.735320] ufshcd-rockchip 2a2d0000.ufshc: Auto BKOPS=0, Host self-block=0
[    2.735931] ufshcd-rockchip 2a2d0000.ufshc: Clk gate=0
[    2.736396] ufshcd-rockchip 2a2d0000.ufshc: last_hibern8_exit_tstamp at 0 us, hibern8_exit_cnt=0
[    2.737166] ufshcd-rockchip 2a2d0000.ufshc: error handling flags=0x0, req. abort count=0
[    2.737875] ufshcd-rockchip 2a2d0000.ufshc: hba->ufs_version=0x200, Host capabilities=0x187011f, caps=0x48c
[    2.738727] ufshcd-rockchip 2a2d0000.ufshc: quirks=0x2000, dev. quirks=0x0
[    2.739349] host_regs: 00000000: 0187011f 00000000 00000200 00000000
[    2.739910] host_regs: 00000010: 00000000 000005e6 00000000 00000000
[    2.740480] host_regs: 00000020: 00000000 00000470 00000000 00000000
[    2.741039] host_regs: 00000030: 00000008 00000001 00000000 00000000
[    2.741598] host_regs: 00000040: 00000000 00000000 00000000 00000000
[    2.742156] host_regs: 00000050: 00000000 00000000 00000000 00000000
[    2.742715] host_regs: 00000060: 00000000 00000000 00000000 00000000
[    2.743273] host_regs: 00000070: 00000000 00000000 00000000 00000000
[    2.743831] host_regs: 00000080: 00000000 00000000 00000000 00000000
[    2.744398] host_regs: 00000090: 00000016 00000000 00000001 00000000
[    2.744959] ufshcd-rockchip 2a2d0000.ufshc: No record of pa_err
[    2.745480] ufshcd-rockchip 2a2d0000.ufshc: No record of dl_err
[    2.746000] ufshcd-rockchip 2a2d0000.ufshc: No record of nl_err
[    2.746520] ufshcd-rockchip 2a2d0000.ufshc: No record of tl_err
[    2.747040] ufshcd-rockchip 2a2d0000.ufshc: No record of dme_err
[    2.747568] ufshcd-rockchip 2a2d0000.ufshc: No record of auto_hibern8_err
[    2.748174] ufshcd-rockchip 2a2d0000.ufshc: No record of fatal_err
[    2.748716] ufshcd-rockchip 2a2d0000.ufshc: link_startup_fail[0] = 0x1 at 2731713 us
[    2.749398] ufshcd-rockchip 2a2d0000.ufshc: link_startup_fail: total cnt=1
[    2.750001] ufshcd-rockchip 2a2d0000.ufshc: No record of resume_fail
[    2.750559] ufshcd-rockchip 2a2d0000.ufshc: No record of suspend_fail
[    2.751125] ufshcd-rockchip 2a2d0000.ufshc: No record of wlun resume_fail
[    2.751721] ufshcd-rockchip 2a2d0000.ufshc: No record of wlun suspend_fail
[    2.752332] ufshcd-rockchip 2a2d0000.ufshc: dev_reset[0] = 0x0 at 2297266 us
[    2.752953] ufshcd-rockchip 2a2d0000.ufshc: dev_reset: total cnt=1
[    2.753497] ufshcd-rockchip 2a2d0000.ufshc: No record of host_reset
[    2.754047] ufshcd-rockchip 2a2d0000.ufshc: No record of task_abort
[    2.755475] ufshcd-rockchip 2a2d0000.ufshc: error 000000000dbbd97c: Initialization failed with error 1
[    2.756358] ufshcd-rockchip 2a2d0000.ufshc: error 000000000dbbd97c: ufshcd_pltfrm_init failed
[    2.757115] ufshcd-rockchip 2a2d0000.ufshc: probe with driver ufshcd-rockchip failed with error 1

I think the best solution would be to avoid this huge error print
in the first place for a completley missing device, but I haven't
checked the details.

Greetings,

-- Sebastian

Re: [PATCH] scsi: core: Fix a regression triggered by scsi_host_busy()

[Bart Van Assche]

On 10/8/25 5:49 AM, Sebastian Reichel wrote:
> The Rock 4D has a pluggable UFS module. UFS is described in the
> system's device-tree, but the affected system itself does not
> have a module plugged in resulting in UFS erroring out early.
> 
> To have an idea - the following is logged at error level because
> no UFS module is plugged:
> 
> [    2.731721] ufshcd-rockchip 2a2d0000.ufshc: link startup failed 1
> [    2.732311] ufshcd-rockchip 2a2d0000.ufshc: UFS Host state=0
> [    2.732812] ufshcd-rockchip 2a2d0000.ufshc: 0 outstanding reqs, tasks=0x0
> [    2.733410] ufshcd-rockchip 2a2d0000.ufshc: saved_err=0x0, saved_uic_err=0x0
> [    2.734030] ufshcd-rockchip 2a2d0000.ufshc: Device power mode=1, UIC link state=0
> [    2.734687] ufshcd-rockchip 2a2d0000.ufshc: PM in progress=0, sys. suspended=0
> [    2.735320] ufshcd-rockchip 2a2d0000.ufshc: Auto BKOPS=0, Host self-block=0
> [    2.735931] ufshcd-rockchip 2a2d0000.ufshc: Clk gate=0
> [    2.736396] ufshcd-rockchip 2a2d0000.ufshc: last_hibern8_exit_tstamp at 0 us, hibern8_exit_cnt=0
> [    2.737166] ufshcd-rockchip 2a2d0000.ufshc: error handling flags=0x0, req. abort count=0
> [    2.737875] ufshcd-rockchip 2a2d0000.ufshc: hba->ufs_version=0x200, Host capabilities=0x187011f, caps=0x48c
> [    2.738727] ufshcd-rockchip 2a2d0000.ufshc: quirks=0x2000, dev. quirks=0x0
> [    2.739349] host_regs: 00000000: 0187011f 00000000 00000200 00000000
> [    2.739910] host_regs: 00000010: 00000000 000005e6 00000000 00000000
> [    2.740480] host_regs: 00000020: 00000000 00000470 00000000 00000000
> [    2.741039] host_regs: 00000030: 00000008 00000001 00000000 00000000
> [    2.741598] host_regs: 00000040: 00000000 00000000 00000000 00000000
> [    2.742156] host_regs: 00000050: 00000000 00000000 00000000 00000000
> [    2.742715] host_regs: 00000060: 00000000 00000000 00000000 00000000
> [    2.743273] host_regs: 00000070: 00000000 00000000 00000000 00000000
> [    2.743831] host_regs: 00000080: 00000000 00000000 00000000 00000000
> [    2.744398] host_regs: 00000090: 00000016 00000000 00000001 00000000
> [    2.744959] ufshcd-rockchip 2a2d0000.ufshc: No record of pa_err
> [    2.745480] ufshcd-rockchip 2a2d0000.ufshc: No record of dl_err
> [    2.746000] ufshcd-rockchip 2a2d0000.ufshc: No record of nl_err
> [    2.746520] ufshcd-rockchip 2a2d0000.ufshc: No record of tl_err
> [    2.747040] ufshcd-rockchip 2a2d0000.ufshc: No record of dme_err
> [    2.747568] ufshcd-rockchip 2a2d0000.ufshc: No record of auto_hibern8_err
> [    2.748174] ufshcd-rockchip 2a2d0000.ufshc: No record of fatal_err
> [    2.748716] ufshcd-rockchip 2a2d0000.ufshc: link_startup_fail[0] = 0x1 at 2731713 us
> [    2.749398] ufshcd-rockchip 2a2d0000.ufshc: link_startup_fail: total cnt=1
> [    2.750001] ufshcd-rockchip 2a2d0000.ufshc: No record of resume_fail
> [    2.750559] ufshcd-rockchip 2a2d0000.ufshc: No record of suspend_fail
> [    2.751125] ufshcd-rockchip 2a2d0000.ufshc: No record of wlun resume_fail
> [    2.751721] ufshcd-rockchip 2a2d0000.ufshc: No record of wlun suspend_fail
> [    2.752332] ufshcd-rockchip 2a2d0000.ufshc: dev_reset[0] = 0x0 at 2297266 us
> [    2.752953] ufshcd-rockchip 2a2d0000.ufshc: dev_reset: total cnt=1
> [    2.753497] ufshcd-rockchip 2a2d0000.ufshc: No record of host_reset
> [    2.754047] ufshcd-rockchip 2a2d0000.ufshc: No record of task_abort
> [    2.755475] ufshcd-rockchip 2a2d0000.ufshc: error 000000000dbbd97c: Initialization failed with error 1
> [    2.756358] ufshcd-rockchip 2a2d0000.ufshc: error 000000000dbbd97c: ufshcd_pltfrm_init failed
> [    2.757115] ufshcd-rockchip 2a2d0000.ufshc: probe with driver ufshcd-rockchip failed with error 1
> 
> I think the best solution would be to avoid this huge error print
> in the first place for a completley missing device, but I haven't
> checked the details.
How about reducing link startup logging with the patch below?

Thanks,

Bart.


Subject: [PATCH] ufs: core: Reduce link startup failure logging

Some systems, e.g. Rock 4D, have a pluggable UFS module. Link startup
fails systematically on these systems. If no UFS module has been plugged
in, more than fourty lines are logged after the "link startup failed"
message. Avoid this by reducing link startup failure logging.

An intended side effect of this patch is that scsi_host_busy() is not
called before scsi_add_host() is called.

Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
  drivers/ufs/core/ufshcd.c | 6 +-----
  1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index 6d1d853ec620..be4bf435da09 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -5117,12 +5117,8 @@ static int ufshcd_link_startup(struct ufs_hba *hba)
  	ufshcd_readl(hba, REG_UIC_ERROR_CODE_PHY_ADAPTER_LAYER);
  	ret = ufshcd_make_hba_operational(hba);
  out:
-	if (ret) {
+	if (ret)
  		dev_err(hba->dev, "link startup failed %d\n", ret);
-		ufshcd_print_host_state(hba);
-		ufshcd_print_pwr_info(hba);
-		ufshcd_print_evt_hist(hba);
-	}
  	return ret;
  }

Re: [PATCH] scsi: core: Fix a regression triggered by scsi_host_busy()

[Bart Van Assche]

On 10/7/25 10:50 PM, Christoph Hellwig wrote:
> On Wed, Oct 08, 2025 at 11:17:18AM +0800, Ming Lei wrote:
>> Long term, the UFS driver need to be fixed, this or most of scsi core
>> APIs should
>> have been called after the scsi host is initialized.
> 
> Please fix ufs now.  Otherwise we'll be stuck with these hacks forever
> as they never get cleaned up.

Although it is easy to make sure that the UFS driver doesn't call
scsi_host_busy() before the SCSI host is added, this is not just a UFS
driver issue. The advansys driver calls scsi_host_busy() as follows 
before scsi_add_host() is called:

  advansys_board_found()
    ASC_DBG_PRT_SCSI_HOST()
      scsi_host_busy()

Thanks,

Bart.

Re: [PATCH] scsi: core: Fix a regression triggered by scsi_host_busy()

[John Garry]

On 07/10/2025 22:48, Bart Van Assche wrote:
> Commit 995412e23bb2 ("blk-mq: Replace tags->lock with SRCU for tag
> iterators") introduced the following regression:
> 
> Call trace:
>   __srcu_read_lock+0x30/0x80 (P)
>   blk_mq_tagset_busy_iter+0x44/0x300
>   scsi_host_busy+0x38/0x70

this value is readable from sysfs, so why even print it?

>   ufshcd_print_host_state+0x34/0x1bc
>   ufshcd_link_startup.constprop.0+0xe4/0x2e0

Re: [PATCH] scsi: core: Fix a regression triggered by scsi_host_busy()

[Bart Van Assche]

On 10/8/25 12:03 AM, John Garry wrote:
> On 07/10/2025 22:48, Bart Van Assche wrote:
>> Commit 995412e23bb2 ("blk-mq: Replace tags->lock with SRCU for tag
>> iterators") introduced the following regression:
>>
>> Call trace:
>>   __srcu_read_lock+0x30/0x80 (P)
>>   blk_mq_tagset_busy_iter+0x44/0x300
>>   scsi_host_busy+0x38/0x70
> 
> this value is readable from sysfs, so why even print it?

That's an interesting question. The infrastructure for reporting Android
bugs includes the kernel logs in a bug report but not the values of
sysfs attributes. Hence, if something unexpected happens, having state
information available in the kernel log helps more than having it
available in sysfs. That being said, I think that the UFS kernel driver
reports more information than it should when an unexpected condition is
met, e.g. a link startup failure or starting the UFS error handler.

Bart.

Re: [PATCH] scsi: core: Fix a regression triggered by scsi_host_busy()

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 2369 bytes --]

Hi,

On Tue, Oct 07, 2025 at 02:48:00PM -0700, Bart Van Assche wrote:
> Commit 995412e23bb2 ("blk-mq: Replace tags->lock with SRCU for tag
> iterators") introduced the following regression:
> 
> Call trace:
>  __srcu_read_lock+0x30/0x80 (P)
>  blk_mq_tagset_busy_iter+0x44/0x300
>  scsi_host_busy+0x38/0x70
>  ufshcd_print_host_state+0x34/0x1bc
>  ufshcd_link_startup.constprop.0+0xe4/0x2e0
>  ufshcd_init+0x944/0xf80
>  ufshcd_pltfrm_init+0x504/0x820
>  ufs_rockchip_probe+0x2c/0x88
>  platform_probe+0x5c/0xa4
>  really_probe+0xc0/0x38c
>  __driver_probe_device+0x7c/0x150
>  driver_probe_device+0x40/0x120
>  __driver_attach+0xc8/0x1e0
>  bus_for_each_dev+0x7c/0xdc
>  driver_attach+0x24/0x30
>  bus_add_driver+0x110/0x230
>  driver_register+0x68/0x130
>  __platform_driver_register+0x20/0x2c
>  ufs_rockchip_pltform_init+0x1c/0x28
>  do_one_initcall+0x60/0x1e0
>  kernel_init_freeable+0x248/0x2c4
>  kernel_init+0x20/0x140
>  ret_from_fork+0x10/0x20
> 
> Fix this regression by making scsi_host_busy() check whether the SCSI
> host tag set has already been initialized. tag_set->ops is set by
> scsi_mq_setup_tags() just before blk_mq_alloc_tag_set() is called. This
> fix is based on the assumption that scsi_host_busy() and
> scsi_mq_setup_tags() calls are serialized. This is the case in the UFS
> driver.
> 
> Reported-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> Closes: https://lore.kernel.org/linux-block/pnezafputodmqlpumwfbn644ohjybouveehcjhz2hmhtcf2rka@sdhoiivync4y/
> Cc: Ming Lei <ming.lei@redhat.com>
> Cc: Jens Axboe <axboe@kernel.dk>
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
> ---

Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com>

-- Sebastian

>  drivers/scsi/hosts.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
> index cc5d05dc395c..17173239301e 100644
> --- a/drivers/scsi/hosts.c
> +++ b/drivers/scsi/hosts.c
> @@ -611,8 +611,9 @@ int scsi_host_busy(struct Scsi_Host *shost)
>  {
>  	int cnt = 0;
>  
> -	blk_mq_tagset_busy_iter(&shost->tag_set,
> -				scsi_host_check_in_flight, &cnt);
> +	if (shost->tag_set.ops)
> +		blk_mq_tagset_busy_iter(&shost->tag_set,
> +					scsi_host_check_in_flight, &cnt);
>  	return cnt;
>  }
>  EXPORT_SYMBOL(scsi_host_busy);

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] scsi: core: Fix a regression triggered by scsi_host_busy()

[Martin K. Petersen]

Bart,

> Commit 995412e23bb2 ("blk-mq: Replace tags->lock with SRCU for tag
> iterators") introduced the following regression:

Applied to 6.18/scsi-fixes, thanks!

-- 
Martin K. Petersen

Re: [PATCH] scsi: core: Fix a regression triggered by scsi_host_busy()

[John Garry]

On 22/10/2025 03:26, Martin K. Petersen wrote:
> 
> Bart,
> 
>> Commit 995412e23bb2 ("blk-mq: Replace tags->lock with SRCU for tag
>> iterators") introduced the following regression:
> 
> Applied to 6.18/scsi-fixes, thanks!
> 

I don't think that we should call scsi_host_busy() on a shost which has 
not been added, so it would be nice to have a plan to fix the LLDs also.

Re: [PATCH] scsi: core: Fix a regression triggered by scsi_host_busy()

[Bart Van Assche]

On 10/22/25 1:13 AM, John Garry wrote:
> On 22/10/2025 03:26, Martin K. Petersen wrote:
>>> Commit 995412e23bb2 ("blk-mq: Replace tags->lock with SRCU for tag
>>> iterators") introduced the following regression:
>>
>> Applied to 6.18/scsi-fixes, thanks!
> 
> I don't think that we should call scsi_host_busy() on a shost which has 
> not been added, so it would be nice to have a plan to fix the LLDs also.

A fix for the UFS driver has already been merged by Martin. See also
"scsi: ufs: core: Reduce link startup failure logging".

Thanks,

Bart.

Re: [PATCH] scsi: core: Fix a regression triggered by scsi_host_busy()

[John Garry]

On 22/10/2025 19:07, Bart Van Assche wrote:
>>>
>>> Applied to 6.18/scsi-fixes, thanks!
>>
>> I don't think that we should call scsi_host_busy() on a shost which 
>> has not been added, so it would be nice to have a plan to fix the LLDs 
>> also.
> 
> A fix for the UFS driver has already been merged by Martin. See also
> "scsi: ufs: core: Reduce link startup failure logging".

Good, so do you know which other drivers need to be fixed? I saw the 
advansys driver mentioned. I can look at sending a fix for that.

Re: [PATCH] scsi: core: Fix a regression triggered by scsi_host_busy()

[Bart Van Assche]

On 10/23/25 1:31 AM, John Garry wrote:
> Good, so do you know which other drivers need to be fixed? I saw the 
> advansys driver mentioned. I can look at sending a fix for that.

The advansys driver is the only driver of which I could determine
quickly that it needs to be fixed. There may be other drivers that
need to be fixed but I'm not sure of this.

Bart.