summaryrefslogtreecommitdiff
path: root/lib/test_context-analysis.c
AgeCommit message (Collapse)Author
2026-03-24compiler: Simplify generic RELOC_HIDE()Marco Elver
When enabling Context Analysis (CONTEXT_ANALYSIS := y) in arch/x86/kvm code, Clang's Thread Safety Analysis failed to recognize that identical per_cpu() accesses refer to the same lock: | CC [M] arch/x86/kvm/vmx/posted_intr.o | arch/x86/kvm/vmx/posted_intr.c:186:2: error: releasing raw_spinlock '__ptr + __per_cpu_offset[vcpu->cpu]' that was not held [-Werror,-Wthread-safety-analysis] | 186 | raw_spin_unlock(&per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu)); | | ^ | ./include/linux/spinlock.h:276:32: note: expanded from macro 'raw_spin_unlock' | 276 | #define raw_spin_unlock(lock) _raw_spin_unlock(lock) | | ^ | arch/x86/kvm/vmx/posted_intr.c:207:1: error: raw_spinlock '__ptr + __per_cpu_offset[vcpu->cpu]' is still held at the end of function [-Werror,-Wthread-safety-analysis] | 207 | } | | ^ | arch/x86/kvm/vmx/posted_intr.c:182:2: note: raw_spinlock acquired here | 182 | raw_spin_lock_nested(&per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu), | | ^ | ./include/linux/spinlock.h:235:2: note: expanded from macro 'raw_spin_lock_nested' | 235 | _raw_spin_lock(((void)(subclass), (lock))) | | ^ | 2 errors generated. This occurred because the default RELOC_HIDE() implementation (used by the per-CPU macros) is a statement expression containing an intermediate 'unsigned long' variable (this version appears to predate Git history). While the analysis strips away inner casts when resolving pointer aliases, it stops when encountering intermediate non-pointer variables (this is Thread Safety Analysis specific and irrelevant for codegen). This prevents the analysis from concluding that the pointers passed to e.g. raw_spin_lock() and raw_spin_unlock() were identical when per-CPU accessors are used. Simplify RELOC_HIDE() to a single expression. This preserves the intent of obfuscating UB-introducing out-of-bounds pointer calculations from the compiler via the 'unsigned long' cast, but allows the alias analysis to successfully resolve the pointers. Using a recent Clang version, I observe that generated code remains the same for vmlinux; the intermediate variable was already being optimized away (for any respectable modern compiler, not doing so would be an optimizer bug). Note that GCC provides its own version of RELOC_HIDE(), so this change only affects Clang builds. Add a test case to lib/test_context-analysis.c to catch any regressions. Reported-by: Bart Van Assche <bvanassche@acm.org> Reported-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/all/e3946223-4543-4a76-a328-9c6865e95192@acm.org/ Link: https://patch.msgid.link/20260319135245.1420780-1-elver@google.com
2026-01-28compiler-context-analysis: Remove __assume_ctx_lock from initializersMarco Elver
Remove __assume_ctx_lock() from lock initializers. Implicitly asserting an active context during initialization caused false-positive double-lock errors when acquiring a lock immediately after its initialization. Moving forward, guarded member initialization must either: 1. Use guard(type_init)(&lock) or scoped_guard(type_init, ...). 2. Use context_unsafe() for simple initialization. Reported-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/all/57062131-e79e-42c2-aa0b-8f931cb8cac2@acm.org/ Link: https://patch.msgid.link/20260119094029.1344361-7-elver@google.com
2026-01-28compiler-context-analysis: Introduce scoped init guardsMarco Elver
Add scoped init guard definitions for common synchronization primitives supported by context analysis. The scoped init guards treat the context as active within initialization scope of the underlying context lock, given initialization implies exclusive access to the underlying object. This allows initialization of guarded members without disabling context analysis, while documenting initialization from subsequent usage. The documentation is updated with the new recommendation. Where scoped init guards are not provided or cannot be implemented (ww_mutex omitted for lack of multi-arg guard initializers), the alternative is to just disable context analysis where guarded members are initialized. Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/all/20251212095943.GM3911114@noisy.programming.kicks-ass.net/ Link: https://patch.msgid.link/20260119094029.1344361-3-elver@google.com
2026-01-05compiler: Let data_race() imply disabled context analysisMarco Elver
Many patterns that involve data-racy accesses often deliberately ignore normal synchronization rules to avoid taking a lock. If we have a lock-guarded variable on which we do a lock-less data-racy access, rather than having to write context_unsafe(data_race(..)), simply make the data_race(..) macro imply context-unsafety. The data_race() macro already denotes the intent that something subtly unsafe is about to happen, so it should be clear enough as-is. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251219154418.3592607-27-elver@google.com
2026-01-05locking/ww_mutex: Support Clang's context analysisMarco Elver
Add support for Clang's context analysis for ww_mutex. The programming model for ww_mutex is subtly more complex than other locking primitives when using ww_acquire_ctx. Encoding the respective pre-conditions for ww_mutex lock/unlock based on ww_acquire_ctx state using Clang's context analysis makes incorrect use of the API harder. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251219154418.3592607-21-elver@google.com
2026-01-05locking/local_lock: Support Clang's context analysisMarco Elver
Add support for Clang's context analysis for local_lock_t and local_trylock_t. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251219154418.3592607-20-elver@google.com
2026-01-05locking/rwsem: Support Clang's context analysisMarco Elver
Add support for Clang's context analysis for rw_semaphore. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251219154418.3592607-18-elver@google.com
2026-01-05srcu: Support Clang's context analysisMarco Elver
Add support for Clang's context analysis for SRCU. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Paul E. McKenney <paulmck@kernel.org> Link: https://patch.msgid.link/20251219154418.3592607-16-elver@google.com
2026-01-05rcu: Support Clang's context analysisMarco Elver
Improve the existing annotations to properly support Clang's context analysis. The old annotations distinguished between RCU, RCU_BH, and RCU_SCHED; however, to more easily be able to express that "hold the RCU read lock" without caring if the normal, _bh(), or _sched() variant was used we'd have to remove the distinction of the latter variants: change the _bh() and _sched() variants to also acquire "RCU". When (and if) we introduce context locks to denote more generally that "IRQ", "BH", "PREEMPT" contexts are disabled, it would make sense to acquire these instead of RCU_BH and RCU_SCHED respectively. The above change also simplified introducing __guarded_by support, where only the "RCU" context lock needs to be held: introduce __rcu_guarded, where Clang's context analysis warns if a pointer is dereferenced without any of the RCU locks held, or updated without the appropriate helpers. The primitives rcu_assign_pointer() and friends are wrapped with context_unsafe(), which enforces using them to update RCU-protected pointers marked with __rcu_guarded. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Paul E. McKenney <paulmck@kernel.org> Link: https://patch.msgid.link/20251219154418.3592607-15-elver@google.com
2026-01-05bit_spinlock: Support Clang's context analysisMarco Elver
The annotations for bit_spinlock.h have simply been using "bitlock" as the token. For Sparse, that was likely sufficient in most cases. But Clang's context analysis is more precise, and we need to ensure we can distinguish different bitlocks. To do so, add a token context, and a macro __bitlock(bitnum, addr) that is used to construct unique per-bitlock tokens. Add the appropriate test. <linux/list_bl.h> is implicitly included through other includes, and requires 2 annotations to indicate that acquisition (without release) and release (without prior acquisition) of its bitlock is intended. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251219154418.3592607-14-elver@google.com
2026-01-05locking/seqlock: Support Clang's context analysisMarco Elver
Add support for Clang's context analysis for seqlock_t. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251219154418.3592607-12-elver@google.com
2026-01-05locking/mutex: Support Clang's context analysisMarco Elver
Add support for Clang's context analysis for mutex. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251219154418.3592607-11-elver@google.com
2026-01-05locking/rwlock, spinlock: Support Clang's context analysisMarco Elver
Add support for Clang's context analysis for raw_spinlock_t, spinlock_t, and rwlock. This wholesale conversion is required because all three of them are interdependent. To avoid warnings in constructors, the initialization functions mark a lock as acquired when initialized before guarded variables. The test verifies that common patterns do not generate false positives. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251219154418.3592607-9-elver@google.com
2026-01-05compiler-context-analysis: Add test stubMarco Elver
Add a simple test stub where we will add common supported patterns that should not generate false positives for each new supported context lock. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251219154418.3592607-4-elver@google.com