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.