doc: RCU callback locks need only _bh, not necessarily _irq

The UP.rst file calls for locks acquired within RCU callback functions
to use _irq variants (spin_lock_irqsave() or similar), which does work,
but can be overkill.  This commit therefore instead calls for _bh variants
(spin_lock_bh() or similar), while noting that _irq does work.

Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
Signed-off-by: Jiunn Chang <c0d1n61at3@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
Jiunn Chang 2019-06-27 16:01:47 -05:00 committed by Jonathan Corbet
parent 62ee81b568
commit acb6258acc
1 changed files with 7 additions and 6 deletions

View File

@ -113,12 +113,13 @@ Answer to Quick Quiz #1:
Answer to Quick Quiz #2: Answer to Quick Quiz #2:
What locking restriction must RCU callbacks respect? What locking restriction must RCU callbacks respect?
Any lock that is acquired within an RCU callback must be Any lock that is acquired within an RCU callback must be acquired
acquired elsewhere using an _irq variant of the spinlock elsewhere using an _bh variant of the spinlock primitive.
primitive. For example, if "mylock" is acquired by an For example, if "mylock" is acquired by an RCU callback, then
RCU callback, then a process-context acquisition of this a process-context acquisition of this lock must use something
lock must use something like spin_lock_irqsave() to like spin_lock_bh() to acquire the lock. Please note that
acquire the lock. it is also OK to use _irq variants of spinlocks, for example,
spin_lock_irqsave().
If the process-context code were to simply use spin_lock(), If the process-context code were to simply use spin_lock(),
then, since RCU callbacks can be invoked from softirq context, then, since RCU callbacks can be invoked from softirq context,