Re: [PATCH] scsi: Do not rescan devices with a suspended queue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi, (adding James)

On Wed,  4 Oct 2023 17:58:03 +0900
Damien Le Moal <dlemoal@xxxxxxxxxx> wrote:

> Commit ff48b37802e5 ("scsi: Do not attempt to rescan suspended devices")
> modified scsi_rescan_device() to avoid attempting rescanning a suspended
> device. However, the modification added a check to verify that a SCSI
> device is in the running state without checking if the device request
> queue (in the case of block device) is also running, thus allowing the
> exectuion of internal requests. Without checking the device request
> queue, commit ff48b37802e5 fix is incomplete and deadlocks on resume can
> still happen. Use blk_queue_pm_only() to check if the device request
> queue allows executing commands in addition to checking the SCSI device
> state.

FTR this fix is still needed for rc5. Is there any chance it goes into
fixes before v6.6 is final?

Petr T

> Reported-by: Petr Tesarik <petr@xxxxxxxxxxx>
> Fixes: ff48b37802e5 ("scsi: Do not attempt to rescan suspended
> devices") Cc: stable@xxxxxxxxxxxxxxx
> Tested-by: Petr Tesarik <petr@xxxxxxxxxxx>
> Signed-off-by: Damien Le Moal <dlemoal@xxxxxxxxxx>
> ---
>  drivers/scsi/scsi_scan.c | 11 ++++++-----
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> index 3db4d31a03a1..b05a55f498a2 100644
> --- a/drivers/scsi/scsi_scan.c
> +++ b/drivers/scsi/scsi_scan.c
> @@ -1627,12 +1627,13 @@ int scsi_rescan_device(struct scsi_device
> *sdev) device_lock(dev);
>  
>  	/*
> -	 * Bail out if the device is not running. Otherwise, the
> rescan may
> -	 * block waiting for commands to be executed, with us
> holding the
> -	 * device lock. This can result in a potential deadlock in
> the power
> -	 * management core code when system resume is on-going.
> +	 * Bail out if the device or its queue are not running.
> Otherwise,
> +	 * the rescan may block waiting for commands to be executed,
> with us
> +	 * holding the device lock. This can result in a potential
> deadlock
> +	 * in the power management core code when system resume is
> on-going. */
> -	if (sdev->sdev_state != SDEV_RUNNING) {
> +	if (sdev->sdev_state != SDEV_RUNNING ||
> +	    blk_queue_pm_only(sdev->request_queue)) {
>  		ret = -EWOULDBLOCK;
>  		goto unlock;
>  	}




[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux