Re: [PATCH] scsi: Wake up the error handler when final completions race against each other

[Bart Van Assche <bvanassche@acm.org>]

On 1/13/26 9:08 AM, David Jeffery wrote:
> The fragile ordering between marking commands completed or failed so that
> the error handler only wakes when the last running command completes or
> times out has race conditions. These race conditions can cause the scsi
> layer to fail to wake the error handler, leaving I/O through the scsi host
> stuck as the error state cannot advance.
> 
> First, there is an memory ordering issue within scsi_dec_host_busy. The
> write which clears SCMD_STATE_INFLIGHT may be reordered with reads counting
> in scsi_host_busy. While the local CPU will see its own write, reordering
> can allow other CPUs in scsi_dec_host_busy or scsi_eh_inc_host_failed to
> see a raised busy count, causing no CPU to see a host busy equal to the
> host_failed count.
> 
> This race condition can be prevented with a memory barrier on the error
> path to force the write to be visible before counting host busy commands.
> 
> Second, there is a general ordering issue with scsi_eh_inc_host_failed. By
> counting busy commands before incrementing host_failed, it can race with a
> final command in scsi_dec_host_busy, such that scsi_dec_host_busy does not
> see host_failed incremented but scsi_eh_inc_host_failed counts busy
> commands before SCMD_STATE_INFLIGHT is cleared by scsi_dec_host_busy,
> resulting in neither waking the error handler task.
> 
> This needs the call to scsi_host_busy to be moved after host_failed is
> incremented to close the race condition.
Reviewed-by: Bart Van Assche <bvanassche@acm.org>