Re: [PATCH v3 1/2] Ensure that the SCSI error handler gets woken up

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

On Wed, 2017-12-06 at 00:17 +0300, ptikhomirov wrote:
> I mean threads in scsi_dec_host_busy() the part under rcu_read_lock are
> divided into two groups: a) finished before call_rcu, b) beginning rcu
> section after call_rcu. So first, in scsi_eh_inc_host_failed() we will
> see all changes to host busy from group (a), second, all threads in group
> (b) will see our change to host_failed. Either there is nobody in (b) and
> we will start EH, or the thread from (b) which entered spin_lock last will
> start EH.
> 
> In your case tasks from b does not see host_failed was incremented, and
> will not start EH.

Hello Pavel,

What does "your case" mean? In my previous e-mail I explained a scenario that
cannot happen so it's not clear to me what "your case" refers to?

Additionally, it seems like you are assuming that RCU guarantees ordering of
RCU read-locked sections against call_rcu()? That's not how RCU works. RCU
guarantees serialization of read-locked sections against grace periods. The
function scsi_eh_inc_host_failed() is invoked through call_rcu() and hence
will be called during a grace period.

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.

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?

Bart.