diff options
author | Uladzislau Rezki (Sony) <[email protected]> | 2024-02-14 14:45:53 -0800 |
---|---|---|
committer | Uladzislau Rezki (Sony) <[email protected]> | 2024-04-15 11:28:59 +0200 |
commit | 058e87782c91696020bdb0aa28ddf77d89aed266 (patch) | |
tree | fde9b02031a9697c2d3b60f732717c3bed246f25 /scripts/gdb/linux/modules.py | |
parent | 3183059ad82a0daa8292daf43c325bac57daceb5 (diff) |
rcu: Update lockdep while in RCU read-side critical section
With Ankur's lazy-/auto-preemption patches applied and with a
lazy-preemptible kernel in combination with a non-preemptible RCU,
lockdep sometimes complains about context switches within RCU read-side
critical sections. This is a false positive due to rcu_read_unlock()
updating lockdep state too late:
__release(RCU);
__rcu_read_unlock();
// Context switch here results in lockdep false positive!!!
rcu_lock_release(&rcu_lock_map); /* Keep acq info for rls diags. */
Although this complaint could also happen with preemptible RCU
in a preemptible kernel, the odds of that happening aer quite low.
In constrast, with non-preemptible RCU, a long critical section has a
high probability of performing a context switch from the preempt_enable()
in __rcu_read_unlock().
The fix is straightforward, just move the rcu_lock_release()
within rcu_read_unlock() to obtain the reverse order from that of
rcu_read_lock():
rcu_lock_release(&rcu_lock_map); /* Keep acq info for rls diags. */
__release(RCU);
__rcu_read_unlock();
This commit makes this change.
Co-developed-by: Frederic Weisbecker <[email protected]>
Signed-off-by: Frederic Weisbecker <[email protected]>
Co-developed-by: Joel Fernandes (Google) <[email protected]>
Signed-off-by: Joel Fernandes (Google) <[email protected]>
Co-developed-by: Boqun Feng <[email protected]>
Signed-off-by: Boqun Feng <[email protected]>
Signed-off-by: Uladzislau Rezki (Sony) <[email protected]>
Reviewed-by: Paul E. McKenney <[email protected]>
Cc: Ankur Arora <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Diffstat (limited to 'scripts/gdb/linux/modules.py')
0 files changed, 0 insertions, 0 deletions