From acb6258acc4fbb76449eec6d0c7ca25254671e31 Mon Sep 17 00:00:00 2001 From: Jiunn Chang Date: Thu, 27 Jun 2019 16:01:47 -0500 Subject: [PATCH] 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 Signed-off-by: Jiunn Chang Signed-off-by: Jonathan Corbet --- Documentation/RCU/UP.rst | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/Documentation/RCU/UP.rst b/Documentation/RCU/UP.rst index 67715a47..e26dda2 100644 --- a/Documentation/RCU/UP.rst +++ b/Documentation/RCU/UP.rst @@ -113,12 +113,13 @@ Answer to Quick Quiz #1: Answer to Quick Quiz #2: What locking restriction must RCU callbacks respect? - Any lock that is acquired within an RCU callback must be - acquired elsewhere using an _irq variant of the spinlock - primitive. For example, if "mylock" is acquired by an - RCU callback, then a process-context acquisition of this - lock must use something like spin_lock_irqsave() to - acquire the lock. + Any lock that is acquired within an RCU callback must be acquired + elsewhere using an _bh variant of the spinlock primitive. + For example, if "mylock" is acquired by an RCU callback, then + a process-context acquisition of this lock must use something + like spin_lock_bh() to acquire the lock. Please note that + 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(), then, since RCU callbacks can be invoked from softirq context, -- 2.7.4