diff options
author | Boqun Feng <boqun.feng@gmail.com> | 2023-01-13 09:59:54 +0300 |
---|---|---|
committer | Boqun Feng <boqun.feng@gmail.com> | 2023-03-27 21:15:59 +0300 |
commit | f0f44752f5f61ee4e3bd88ae033fdb888320aafe (patch) | |
tree | 0cbab17b4ff02f74ba556e295f1763bef09a2498 /kernel/locking | |
parent | 2f1f043e7bea3fbf4c1869df2f7a0312bc8ca2bf (diff) | |
download | linux-f0f44752f5f61ee4e3bd88ae033fdb888320aafe.tar.xz |
rcu: Annotate SRCU's update-side lockdep dependencies
Although all flavors of RCU readers are annotated correctly with
lockdep as recursive read locks, they do not set the lock_acquire
'check' parameter. This means that RCU read locks are not added to
the lockdep dependency graph, which in turn means that lockdep cannot
detect RCU-based deadlocks. This is not a problem for RCU flavors having
atomic read-side critical sections because context-based annotations can
catch these deadlocks, see for example the RCU_LOCKDEP_WARN() statement
in synchronize_rcu(). But context-based annotations are not helpful
for sleepable RCU, especially given that it is perfectly legal to do
synchronize_srcu(&srcu1) within an srcu_read_lock(&srcu2).
However, we can detect SRCU-based by: (1) Making srcu_read_lock() a
'check'ed recursive read lock and (2) Making synchronize_srcu() a empty
write lock critical section. Even better, with the newly introduced
lock_sync(), we can avoid false positives about irq-unsafe/safe.
This commit therefore makes it so.
Note that NMI-safe SRCU read side critical sections are currently not
annotated, but might be annotated in the future.
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
[ boqun: Add comments for annotation per Waiman's suggestion ]
[ boqun: Fix comment warning reported by Stephen Rothwell ]
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Diffstat (limited to 'kernel/locking')
0 files changed, 0 insertions, 0 deletions