Re: [PATCH v2 1/4] scsi: sd: Let sd_shutdown() fail future I/O

[James Bottomley <jejb@linux.ibm.com>]

On Wed, 2023-04-19 at 10:58 -0700, Bart Van Assche wrote:
> On 4/19/23 07:02, James Bottomley wrote:
> > device_shutdown() goes in reverse devices_kset->list order, so it
> > looks like it would do the PCI device then the SCSI device then the
> > ULD then block, so we can use the queues in SCSI for emergency
> > actions (like flush or stop) before block goes down.  Although this
> > isn't guaranteed; there are things, like device_link_add, which
> > reorder this kset, so we'd need to make sure the above assumption
> > is correct.
> 
> Hi James,
> 
> My understanding is that both the block device associated with 
> /dev/sd<x> and the struct scsi_disk associated with the same SCSI
> device have the sdev_gendev member of struct scsi_device as parent.
> In other words, without creating device links, there are no
> guarantees about the order in which the .shutdown() methods of struct
> block_device.bd_device  and struct scsi_disk.disk_dev are called.
> Adding device links seems like an unnecessary complexity to me. Hence
> my preference to make sd_shutdown() responsible for quiescing future
> SCSI command activity.

So if we can't reliably get it right, let's not do it at all.  The
previous argument you made was about problems with I/O to shutdown PCI
devices.  That's not SCSI specific, so either we fix it for everything
or decide it's not really a problem for anything.

James