mirror of
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
synced 2025-09-18 22:14:16 +00:00
doc: Update UP.rst
This commit updates UP.rst to reflect changes over the past few years, including the advent of userspace RCU libraries for constrained systems. Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
This commit is contained in:
parent
0c208a7930
commit
c8f2310e21
1 changed files with 11 additions and 2 deletions
|
@ -38,7 +38,7 @@ by having call_rcu() directly invoke its arguments only if it was called
|
||||||
from process context. However, this can fail in a similar manner.
|
from process context. However, this can fail in a similar manner.
|
||||||
|
|
||||||
Suppose that an RCU-based algorithm again scans a linked list containing
|
Suppose that an RCU-based algorithm again scans a linked list containing
|
||||||
elements A, B, and C in process contexts, but that it invokes a function
|
elements A, B, and C in process context, but that it invokes a function
|
||||||
on each element as it is scanned. Suppose further that this function
|
on each element as it is scanned. Suppose further that this function
|
||||||
deletes element B from the list, then passes it to call_rcu() for deferred
|
deletes element B from the list, then passes it to call_rcu() for deferred
|
||||||
freeing. This may be a bit unconventional, but it is perfectly legal
|
freeing. This may be a bit unconventional, but it is perfectly legal
|
||||||
|
@ -59,7 +59,8 @@ Example 3: Death by Deadlock
|
||||||
Suppose that call_rcu() is invoked while holding a lock, and that the
|
Suppose that call_rcu() is invoked while holding a lock, and that the
|
||||||
callback function must acquire this same lock. In this case, if
|
callback function must acquire this same lock. In this case, if
|
||||||
call_rcu() were to directly invoke the callback, the result would
|
call_rcu() were to directly invoke the callback, the result would
|
||||||
be self-deadlock.
|
be self-deadlock *even if* this invocation occurred from a later
|
||||||
|
call_rcu() invocation a full grace period later.
|
||||||
|
|
||||||
In some cases, it would possible to restructure to code so that
|
In some cases, it would possible to restructure to code so that
|
||||||
the call_rcu() is delayed until after the lock is released. However,
|
the call_rcu() is delayed until after the lock is released. However,
|
||||||
|
@ -85,6 +86,14 @@ Quick Quiz #2:
|
||||||
|
|
||||||
:ref:`Answers to Quick Quiz <answer_quick_quiz_up>`
|
:ref:`Answers to Quick Quiz <answer_quick_quiz_up>`
|
||||||
|
|
||||||
|
It is important to note that userspace RCU implementations *do*
|
||||||
|
permit call_rcu() to directly invoke callbacks, but only if a full
|
||||||
|
grace period has elapsed since those callbacks were queued. This is
|
||||||
|
the case because some userspace environments are extremely constrained.
|
||||||
|
Nevertheless, people writing userspace RCU implementations are strongly
|
||||||
|
encouraged to avoid invoking callbacks from call_rcu(), thus obtaining
|
||||||
|
the deadlock-avoidance benefits called out above.
|
||||||
|
|
||||||
Summary
|
Summary
|
||||||
-------
|
-------
|
||||||
|
|
||||||
|
|
Loading…
Add table
Reference in a new issue