[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e081cc6b-65a5-6d95-9a4c-da1ca454d754@acm.org>
Date: Sun, 16 Apr 2023 14:29:01 -0700
From: Bart Van Assche <bvanassche@....org>
To: John Garry <john.g.garry@...cle.com>, jejb@...ux.ibm.com,
martin.petersen@...cle.com, dgilbert@...erlog.com
Cc: linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
kernel test robot <yujie.liu@...el.com>
Subject: Re: [PATCH] scsi: scsi_debug: Abort commands from
scsi_debug_device_reset()
On 4/16/23 10:56, John Garry wrote:
> Currently scsi_debug_device_reset() does not do much apart from setting
> the SDEBUG_UA_POR ("Power on, reset, or bus device reset") flag, which is
> eventually passed back to the SCSI midlayer later for a "unit attention"
> command.
>
> There is a report that blktest scsi/007 test fails due to commit
> 1107c7b24ee3 ("scsi: scsi_debug: Dynamically allocate sdebug_queued_cmd").
> The problem there is that there are dangling scsi_debug queued commands
> when we attempt to remove the driver.
>
> scsi/007 test triggers SCSI EH and attempts to abort a timed-out command.
> Function scsi_debug_device_reset() is called as part of the EH, but does
> not deal with outstanding erroneous command. Prior to the named commit,
> removing the driver caused all dangling queued commands to be stopped -
> this should have not been necessary.
>
> Fix by aborting outstanding commands on a scsi_device basis from
> scsi_debug_device_reset().
>
> Fixes: 1107c7b24ee3 ("scsi: scsi_debug: Dynamically allocate sdebug_queued_cmd")
> Reported-by: kernel test robot <yujie.liu@...el.com>
> Link: https://lore.kernel.org/oe-lkp/202304071111.e762fcbd-yujie.liu@intel.com
> Signed-off-by: John Garry <john.g.garry@...cle.com>
Reviewed-by: Bart Van Assche <bvanassche@....org>
Powered by blists - more mailing lists