redonkable
/
alistair23-linux
1
0
Fork 0
Code Releases Activity

doc: CPU-hotplug notifiers cannot invoke synchronize_srcu() or srcu_barrier() 

SRCU's synchronize_srcu() may not be invoked from CPU-hotplug notifiers,
due to the fact that SRCU grace periods make use of timers and the
possibility of timers being temporarily stranded on the outgoing CPU.
This stranding of timers means that timers posted to the outgoing CPU
will not fire until late in the CPU-hotplug process.  The problem is
that if a notifier is waiting on an SRCU grace period, that grace period
is waiting on a timer, and that timer is stranded on the outgoing CPU,
then the notifier will never be awakened, in other words, deadlock has
occurred.  This same situation of course also prohibits srcu_barrier()
from being invoked from CPU-hotplug notifiers.

This commit therefore updates the requirements to include this restriction.

Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
hifive-unleashed-5.1
Paul E. McKenney 2018-12-11 08:28:56 -08:00
parent 1a4762b927
commit 6efebf8499
1 changed files with 13 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
Documentation/RCU/Design/Requirements/Requirements.html
View File

@ -3099,7 +3099,7 @@ If you block forever in one of a given domain's SRCU read-side critical
sections, then that domain's grace periods will also be blocked forever. sections, then that domain's grace periods will also be blocked forever.
Of course, one good way to block forever is to deadlock, which can Of course, one good way to block forever is to deadlock, which can
happen if any operation in a given domain's SRCU read-side critical happen if any operation in a given domain's SRCU read-side critical
section can block waiting, either directly or indirectly, for that domain's section can wait, either directly or indirectly, for that domain's
grace period to elapse. grace period to elapse.
For example, this results in a self-deadlock: For example, this results in a self-deadlock:
@ -3139,12 +3139,18 @@ API, which, in combination with <tt>srcu_read_unlock()</tt>,
guarantees a full memory barrier. guarantees a full memory barrier.
<p> <p>
Also unlike other RCU flavors, SRCU's callbacks-wait function Also unlike other RCU flavors, <tt>synchronize_srcu()</tt> may <b>not</b>
<tt>srcu_barrier()</tt> may be invoked from CPU-hotplug notifiers, be invoked from CPU-hotplug notifiers, due to the fact that SRCU grace
though this is not necessarily a good idea. periods make use of timers and the possibility of timers being temporarily
The reason that this is possible is that SRCU is insensitive &ldquo;stranded&rdquo; on the outgoing CPU.
to whether or not a CPU is online, which means that <tt>srcu_barrier()</tt> This stranding of timers means that timers posted to the outgoing CPU
need not exclude CPU-hotplug operations. will not fire until late in the CPU-hotplug process.
The problem is that if a notifier is waiting on an SRCU grace period,
that grace period is waiting on a timer, and that timer is stranded on the
outgoing CPU, then the notifier will never be awakened, in other words,
deadlock has occurred.
This same situation of course also prohibits <tt>srcu_barrier()</tt>
from being invoked from CPU-hotplug notifiers.
<p> <p>
SRCU also differs from other RCU flavors in that SRCU's expedited and SRCU also differs from other RCU flavors in that SRCU's expedited and