On Wed, 2017-12-06 at 01:49 +0300, Pavel Tikhomirov wrote: > On 12/06/2017 12:46 AM, Bart Van Assche wrote: > > Anyway, the different scenarios I see are as follows: > > (a) scsi_dec_host_busy() finishes before scsi_eh_inc_host_failed() starts. > > (b) scsi_dec_host_busy() starts after scsi_eh_inc_host_failed() has > > finished. > > So I think in (b) scsi_dec_host_busy starts after scsi_eh_inc_host_failed > has _started_. Agreed, and that's fine, since in that case the SCSI host state has alread been modified and hence both functions will obtain the SCSI host lock. The relevant code will be serialized through the SCSI host lock. > > In case (a) scsi_eh_inc_host_failed() will wake up the error handler. And in > > case (b) scsi_dec_host_busy() will wake up the error handler. So it's not > > clear to me why you think that there is a scenario in which the EH won't be > > woken up? > > So in case (b), in my understanding, scsi_dec_host_busy can skip wakeups > as it does not see host_failed change yet. That's not correct. If scsi_dec_host_busy() obtains the SCSI host lock before scsi_eh_inc_host_failed() obtains it then the latter function will trigger a SCSI EH wakeup. Bart.