On Tue, 2018-04-03 at 10:11 +0530, Sreekanth Reddy wrote: > [SR] No, driver calls _scsih_flush_running_cmds during Host reset time > and during host reset time driver will set 'ioc->shost_recovery' flag. > So in the scsih_qcmd() driver will return the incoming SCSI cmds with > "SCSI_MLQUEUE_HOST_BUSY" whenever 'ioc->shost_recovery' flag is set as > shown below, > > /* host recovery or link resets sent via IOCTLs */ > if (ioc->shost_recovery || ioc->ioc_link_reset_in_progress) > return SCSI_MLQUEUE_HOST_BUSY;
The ioc->shost_recovery flag is involved in at least the following race: * From one context a SCSI command is submitted and scsih_qcmd() gets called. * At the same time sg_reset is invoked from a shell and triggers a call to scsih_host_reset(). That function in turn will call mpt3sas_base_hard_reset_handler(). I think this scenario can cause ioc->shost_recovery to be set by the mpt3sas driver after it has been checked by the scsih_qcmd() function. Anyway, let's get back to patch 03/15 at the start of this e-mail thread. That patch looks to me like an incomplete attempt to work around a race condition in the mpt3sas driver. I don't expect that anyone will trust that patch without further explanation. Which race condition does that patch address? And why do the mpt3sas maintainers believe that this patch is sufficient to address that race condition? Thanks, Bart.
