aboutsummaryrefslogtreecommitdiffstats
path: root/scripts/rustdoc_test_gen.rs
diff options
context:
space:
mode:
authorPaul E. McKenney <[email protected]>2025-01-29 02:32:49 +0000
committerBoqun Feng <[email protected]>2025-02-05 15:12:06 +0000
commit3cec27453db49a176e688b7721c3cd26be5ef835 (patch)
tree93c9f7472e8c5bf00677dd1bff96bab0e6e16321 /scripts/rustdoc_test_gen.rs
parentsrcu: Add srcu_down_read_fast() and srcu_up_read_fast() (diff)
downloadkernel-3cec27453db49a176e688b7721c3cd26be5ef835.tar.gz
kernel-3cec27453db49a176e688b7721c3cd26be5ef835.zip
srcu: Make SRCU-fast also be NMI-safe
BPF uses rcu_read_lock_trace() in NMI context, so srcu_read_lock_fast() must be NMI-safe if it is to have any chance of addressing RCU Tasks Trace use cases. This commit therefore causes srcu_read_lock_fast() and srcu_read_unlock_fast() to use atomic_long_inc() instead of this_cpu_inc() on architectures that support NMIs but do not have NMI-safe implementations of this_cpu_inc(). Note that both x86 and arm64 have NMI-safe implementations of this_cpu_inc(), and thus do not pay the performance penalty inherent in atomic_inc_long(). It is tempting to use this trick to fold srcu_read_lock_nmisafe() into srcu_read_lock(), but this would need careful thought, review, and performance analysis. Though those smp_mb() calls might well make performance a non-issue. Reported-by: Alexei Starovoitov <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]> Signed-off-by: Boqun Feng <[email protected]>
Diffstat (limited to 'scripts/rustdoc_test_gen.rs')
0 files changed, 0 insertions, 0 deletions