doc: RCU callback locks need only _bh, not necessarily _irq (acb6258a) · Commits · 戴 / test

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>

Documentation/RCU/UP.rst

+7 −6

Original line number	Diff line number	Diff line
		@@ -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,

Admin message