Re: [PATCH v3 04/12] Protect SCSI device state changes with a mutex

[Bart Van Assche <Bart.VanAssche@sandisk.com>]

On Mon, 2017-06-05 at 15:18 +0000, Bart Van Assche wrote:
> On Mon, 2017-06-05 at 10:09 +0200, Christoph Hellwig wrote:
> > On Fri, Jun 02, 2017 at 02:21:55PM -0700, Bart Van Assche wrote:
> > > Serializing SCSI device state changes avoids that two state changes
> > > can occur concurrently, e.g. the state changes in scsi_target_block()
> > > and __scsi_remove_device(). This serialization is essential to make
> > > patch "Make __scsi_remove_device go straight from BLOCKED to DEL"
> > > work reliably.
> > > 
> > > Enable this mechanism for all scsi_target_*block() callers but not
> > > for the scsi_internal_device_unblock() calls from the mpt3sas driver
> > > because that driver can call scsi_internal_device_unblock() from
> > > atomic context.
> > 
> > And not taking the lock in that path is safe because of what conditions?
> 
> The mpt3sas driver is the only driver that calls scsi_internal_device_block()
> and scsi_internal_device_unblock() from atomic context. Since it's not an option
> to protect the SCSI device state changes with a spinlock I prefer that the
> mpt3sas authors convert the scsi_internal_device_block() calls into
> scsi_target_block() calls.

Please also note that although this patch series doesn't improve the mpt3sas
driver, it doesn't change its behavior.

Bart.