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? Hello Christoph, 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. Bart.
