summaryrefslogtreecommitdiff
path: root/mm/rmap.c
diff options
context:
space:
mode:
authorThomas Gleixner <tglx@linutronix.de>2021-09-23 18:54:46 +0200
committerPeter Zijlstra <peterz@infradead.org>2021-10-01 13:57:51 +0200
commitef1f4804b27a54da34de6984d16f1fe8f2cc7011 (patch)
treee71b16b881af4a56507699b96f3f810428fb72b1 /mm/rmap.c
parent3e9cc688e56cc2abb9b6067f57c8397f6c96d42c (diff)
locking/rt: Take RCU nesting into account for __might_resched()
The general rule that rcu_read_lock() held sections cannot voluntary sleep does apply even on RT kernels. Though the substitution of spin/rw locks on RT enabled kernels has to be exempt from that rule. On !RT a spin_lock() can obviously nest inside a RCU read side critical section as the lock acquisition is not going to block, but on RT this is not longer the case due to the 'sleeping' spinlock substitution. The RT patches contained a cheap hack to ignore the RCU nesting depth in might_sleep() checks, which was a pragmatic but incorrect workaround. Instead of generally ignoring the RCU nesting depth in __might_sleep() and __might_resched() checks, pass the rcu_preempt_depth() via the offsets argument to __might_resched() from spin/read/write_lock() which makes the checks work correctly even in RCU read side critical sections. The actual blocking on such a substituted lock within a RCU read side critical section is already handled correctly in __schedule() by treating it as a "preemption" of the RCU read side critical section. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20210923165358.368305497@linutronix.de
Diffstat (limited to 'mm/rmap.c')
0 files changed, 0 insertions, 0 deletions