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

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>
alistair/sunxi64-5.4-dsi
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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
Documentation/RCU/UP.rst
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,