summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2026-01-09rust: sync: atomic: Add i8/i16 load and store supportFUJITA Tomonori2-7/+32
Add atomic operation support for i8 and i16 types using volatile read/write and smp_load_acquire/smp_store_release helpers. [boqun: Adjust [1] to avoid introduction of impl_atomic_only_load_and_store_ops!() in the middle] Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Link: https://lore.kernel.org/all/20251228120546.1602275-1-fujita.tomonori@gmail.com/ [1] Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251211113826.1299077-4-fujita.tomonori@gmail.com
2026-01-09arch: um/x86: Select ARCH_SUPPORTS_ATOMIC_RMW for UML_X86Boqun Feng1-0/+1
x86 atomic instructions are used for um on UML_X86, therefore atomics on UML_X86 support native atomic RmW as x86 does, hence select ARCH_SUPPORTS_ATOMIC_RMW. Reviewed-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Acked-by: Richard Weinberger <richard@nod.at> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20260106034034.60074-1-boqun.feng@gmail.com
2026-01-09rust: sync: atomic: Prepare AtomicOps macros for i8/i16 supportFUJITA Tomonori1-19/+66
Rework the internal AtomicOps macro plumbing to generate per-type implementations from a mapping list. Capture the trait definition once and reuse it for both declaration and per-type impl expansion to reduce duplication and keep future extensions simple. This is a preparatory refactor for enabling i8/i16 atomics cleanly. Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251228120546.1602275-2-fujita.tomonori@gmail.com
2026-01-09rust: helpers: Add i8/i16 atomic try_cmpxchg_relaxed helpersFUJITA Tomonori1-0/+10
Add i8/i16 atomic try_cmpxchg_relaxed helpers that call try_cmpxchg_relaxed() macro implementing atomic try_cmpxchg_relaxed using architecture-specific instructions. [boqun: Use try_cmpxchg_relaxed() instead of raw_try_cmpxchg_relaxed()] Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251227115951.1424458-5-fujita.tomonori@gmail.com
2026-01-09rust: helpers: Add i8/i16 atomic try_cmpxchg_release helpersFUJITA Tomonori1-0/+10
Add i8/i16 atomic try_cmpxchg_release helpers that call try_cmpxchg_release() macro implementing atomic try_cmpxchg_release using architecture-specific instructions. [boqun: Use try_cmpxchg_release() instead of raw_try_cmpxchg_release()] Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251227115951.1424458-4-fujita.tomonori@gmail.com
2026-01-09rust: helpers: Add i8/i16 atomic try_cmpxchg_acquire helpersFUJITA Tomonori1-0/+10
Add i8/i16 atomic try_cmpxchg_acquire helpers that call try_cmpxchg_acquire() macro implementing atomic try_cmpxchg_acquire using architecture-specific instructions. [boqun: Use try_cmpxchg_acquire() instead of raw_try_cmpxchg_acquire()] Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251227115951.1424458-3-fujita.tomonori@gmail.com
2026-01-09rust: helpers: Add i8/i16 atomic try_cmpxchg helpersFUJITA Tomonori1-0/+17
Add i8/i16 atomic try_cmpxchg helpers that call try_cmpxchg() macro implementing atomic try_cmpxchg using architecture-specific instructions. [boqun: Add comments explaining CONFIG_ARCH_SUPPORTS_ATOMIC_RMW and use try_cmpxchg() instead of raw_try_cmpxchg()] Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251227115951.1424458-2-fujita.tomonori@gmail.com
2026-01-09rust: helpers: Add i8/i16 atomic xchg_relaxed helpersFUJITA Tomonori1-0/+10
Add i8/i16 atomic xchg_relaxed helpers that call xchg_relaxed() macro implementing atomic xchg_relaxed using architecture-specific instructions. [boqun: Use xchg_relaxed() instead of raw_xchg_relaxed()] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251223062140.938325-5-fujita.tomonori@gmail.com
2026-01-09rust: helpers: Add i8/i16 atomic xchg_release helpersFUJITA Tomonori1-0/+10
Add i8/i16 atomic xchg_release helpers that call xchg_release() macro implementing atomic xchg_release using architecture-specific instructions. [boqun: Use xchg_release() instead of raw_xchg_release()] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251223062140.938325-4-fujita.tomonori@gmail.com
2026-01-09rust: helpers: Add i8/i16 atomic xchg_acquire helpersFUJITA Tomonori1-0/+10
Add i8/i16 atomic xchg_acquire helpers that call xchg_acquire() macro implementing atomic xchg_acquire using architecture-specific instructions. [boqun: Use xchg_acquire() instead of raw_xchg_acquire()] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251223062140.938325-3-fujita.tomonori@gmail.com
2026-01-09rust: helpers: Add i8/i16 atomic xchg helpersFUJITA Tomonori1-0/+18
Add i8/i16 atomic xchg helpers that call xchg() macro implementing atomic xchg using architecture-specific instructions. [boqun: Use xchg() instead of raw_xchg()] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251223062140.938325-2-fujita.tomonori@gmail.com
2026-01-09rust: helpers: Add i8/i16 relaxed atomic helpersFUJITA Tomonori1-0/+21
Add READ_ONCE/WRITE_ONCE based helpers for i8 and i16 types to support relaxed atomic operations in Rust. While relaxed operations could be implemented purely in Rust using read_volatile() and write_volatile(), using C's READ_ONCE() and WRITE_ONCE() macros ensures complete consistency with the kernel memory model. These helpers expose different symbol names than their C counterparts so they are split into atomic_ext.c instead of atomic.c. The symbol names; the names make the interface Rust/C clear, consistent with i32/i64. [boqun: Rename the functions from {load,store} to {read,set} to avoid future adjustment] Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251211113826.1299077-3-fujita.tomonori@gmail.com
2026-01-09rust: helpers: Add i8/i16 atomic_read_acquire/atomic_set_release helpersFUJITA Tomonori2-0/+24
Add helper functions to expose smp_load_acquire() and smp_store_release() for i8 and i16 types. The smp_load_acquire() and smp_store_release() macros require type information (sizeof) to generate appropriate architecture-specific memory ordering instructions. Therefore, separate helper functions are needed for each type size. These helpers expose different symbol names than their C counterparts so they are split into atomic_ext.c instead of atomic.c. The symbol names; atomic_[i8|i16]_read_acquire and atomic_[i8|i16]_set_release makes the interface Rust/C clear, consistent with i32/i64. These helpers will be used by the upcoming Atomic<i8> and Atomic<i16> implementation to provide proper Acquire/Release semantics across all architectures. [boqun: Rename the functions from {load,store} to {read,set} to avoid future adjustment] Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251211113826.1299077-2-fujita.tomonori@gmail.com
2026-01-09rust: sync: Implement Unpin for ARefAlice Ryhl1-0/+3
The default implementation of Unpin for ARef<T> is conditional on T being Unpin due to its PhantomData<T> field. However, this is overly strict as pointers to T are legal to move even if T itself cannot move. Since commit 66f1ea83d9f8 ("rust: lock: Add a Pin<&mut T> accessor") this causes build failures when combined with a Mutex that contains an field ARef<T>, because almost any type that ARef is used with is !Unpin. Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Benno Lossin <lossin@kernel.org> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251218-unpin-for-aref-v2-1-30d77129cbc6@google.com
2026-01-09rust: sync: set_once: Implement Send and SyncFUJITA Tomonori1-0/+8
Implement Send and Sync for SetOnce<T> to allow it to be used across thread boundaries. Send: SetOnce<T> can be transferred across threads when T: Send, as the contained value is also transferred and will be dropped on the destination thread. Sync: SetOnce<T> can be shared across threads when T: Sync, as as_ref() provides shared references &T and atomic operations ensure proper synchronization. Since the inner T may be dropped on any thread, we also require T: Send. Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251216000901.221375-1-fujita.tomonori@gmail.com
2026-01-09rust: sync: Clean up LockClassKey and its docsAlice Ryhl1-14/+40
Several aspects of the code and documentation for this type is incomplete. Also several things are hidden from the docs. Thus, clean it up and make it easier to read the rendered html docs. Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <lossin@kernel.org> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20250811-lock-class-key-cleanup-v3-2-b12967ee1ca2@google.com
2026-01-09rust: sync: Refactor static_lock_class!() macroAlice Ryhl1-6/+18
By introducing a new_static() constructor, the macro does not need to go through MaybeUninit::uninit().assume_init(), which is a pattern that is best avoided when possible. The safety comment not only requires that the value is leaked, but also that it is stored in the right portion of memory. This is so that the lockdep static_obj() check will succeed when using this constructor. One could argue that lockdep detects this scenario, so that safety requirement isn't needed. However, it simplifies matters to require that static_obj() will succeed and it's not a burdensome requirement on the caller. Suggested-by: Benno Lossin <lossin@kernel.org> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Benno Lossin <lossin@kernel.org> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20250811-lock-class-key-cleanup-v3-1-b12967ee1ca2@google.com
2026-01-08locking/local_lock: Include more missing headersPeter Zijlstra1-0/+1
Ingo reported PREEMPT_RT=y builds fail building lib/test_context-analysis.c. Reported-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
2026-01-08compiler-context-analysys: Fix CONFIG_MODVERSIONMarco Elver1-1/+1
The robot reported CONFIG_MODVERSION fails; which Nathan described as so: > Something about the context analysis makes genksyms fall over, running > it manually on kernel/sched/core.i with '-w' to show warnings reveals > many new "syntax error" instances. I don't see any warnings when using > gendwarfksyms. Maybe it is context_lock_struct, as that is the first > error I see in the list: > > include/linux/spinlock_types_raw.h:14: syntax error Reported-by: kernel test robot <lkp@intel.com> Debugged-by: Nathan Chancellor <nathan@kernel.org> Closes: https://lore.kernel.org/oe-kbuild-all/202512222219.F6EkVNmQ-lkp@intel.com/ Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/aV7fxXjaOBtHhI9X@elver.google.com
2026-01-06scripts/atomic: Fix kerneldoc spelling in try_cmpxchg()oldzhu4-28/+28
Fix a typo in the kerneldoc comment template. This changes 'occured' to 'occurred' in generated documentation. Signed-off-by: oldzhu <oldrunner999@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260106040158.31461-1-oldrunner999@gmail.com
2026-01-05tags: Add regex for context_lock_structPeter Zijlstra1-0/+1
With the introduction of compiler context analysis (LLVM ThreadSafetyAnalysis) the struct definition of various locks get wrapped in a macro. This hides them from tags based navigation, although clangd/LSP sees right through it and works as expected. Add a regex to the tags script to help it along. Requested-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251220133307.GR3707891@noisy.programming.kicks-ass.net
2026-01-05sched: Enable context analysis for core.c and fair.cMarco Elver9-68/+177
This demonstrates a larger conversion to use Clang's context analysis. The benefit is additional static checking of locking rules, along with better documentation. Notably, kernel/sched contains sufficiently complex synchronization patterns, and application to core.c & fair.c demonstrates that the latest Clang version has become powerful enough to start applying this to more complex subsystems (with some modest annotations and changes). Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251219154418.3592607-37-elver@google.com
2026-01-05crypto: Enable context analysisMarco Elver11-21/+35
Enable context analysis for crypto subsystem. This demonstrates a larger conversion to use Clang's context analysis. The benefit is additional static checking of locking rules, along with better documentation. Note the use of the __acquire_ret macro how to define an API where a function returns a pointer to an object (struct scomp_scratch) with a lock held. Additionally, the analysis only resolves aliases where the analysis unambiguously sees that a variable was not reassigned after initialization, requiring minor code changes. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251219154418.3592607-36-elver@google.com
2026-01-05security/tomoyo: Enable context analysisMarco Elver9-49/+122
Enable context analysis for security/tomoyo. This demonstrates a larger conversion to use Clang's context analysis. The benefit is additional static checking of locking rules, along with better documentation. Tomoyo makes use of several synchronization primitives, yet its clear design made it relatively straightforward to enable context analysis. One notable finding was: security/tomoyo/gc.c:664:20: error: reading variable 'write_buf' requires holding mutex '&tomoyo_io_buffer::io_sem' 664 | is_write = head->write_buf != NULL; For which Tetsuo writes: "Good catch. This should be data_race(), for tomoyo_write_control() might concurrently update head->write_buf from non-NULL to non-NULL with head->io_sem held." Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251219154418.3592607-35-elver@google.com
2026-01-05printk: Move locking annotation to printk.cMarco Elver2-2/+4
With Sparse support gone, Clang is a bit more strict and warns: ./include/linux/console.h:492:50: error: use of undeclared identifier 'console_mutex' 492 | extern void console_list_unlock(void) __releases(console_mutex); Since it does not make sense to make console_mutex itself global, move the annotation to printk.c. Context analysis remains disabled for printk.c. This is needed to enable context analysis for modules that include <linux/console.h>. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251219154418.3592607-34-elver@google.com
2026-01-05rhashtable: Enable context analysisMarco Elver3-5/+18
Enable context analysis for rhashtable, which was used as an initial test as it contains a combination of RCU, mutex, and bit_spinlock usage. Users of rhashtable now also benefit from annotations on the API, which will now warn if the RCU read lock is not held where required. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251219154418.3592607-33-elver@google.com
2026-01-05stackdepot: Enable context analysisMarco Elver2-6/+15
Enable context analysis for stackdepot. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251219154418.3592607-32-elver@google.com
2026-01-05kcsan: Enable context analysisMarco Elver2-3/+10
Enable context analysis for the KCSAN subsystem. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251219154418.3592607-31-elver@google.com
2026-01-05kcov: Enable context analysisMarco Elver2-11/+27
Enable context analysis for the KCOV subsystem. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251219154418.3592607-30-elver@google.com
2026-01-05kfence: Enable context analysisMarco Elver4-15/+25
Enable context analysis for the KFENCE subsystem. Notable, kfence_handle_page_fault() required minor restructure, which also fixed a subtle race; arguably that function is more readable now. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251219154418.3592607-29-elver@google.com
2026-01-05MAINTAINERS: Add entry for Context AnalysisMarco Elver1-0/+11
Add entry for all new files added for Clang's context analysis. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Link: https://patch.msgid.link/20251219154418.3592607-28-elver@google.com
2026-01-05compiler: Let data_race() imply disabled context analysisMarco Elver2-0/+4
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-05compiler-context-analysis: Introduce header suppressionsMarco Elver2-0/+36
While we can opt in individual subsystems which add the required annotations, such subsystems inevitably include headers from other subsystems which may not yet have the right annotations, which then result in false positive warnings. Making compatible by adding annotations across all common headers currently requires an excessive number of __no_context_analysis annotations, or carefully analyzing non-trivial cases to add the correct annotations. While this is desirable long-term, providing an incremental path causes less churn and headaches for maintainers not yet interested in dealing with such warnings. Rather than clutter headers unnecessary and mandate all subsystem maintainers to keep their headers working with context analysis, suppress all -Wthread-safety warnings in headers. Explicitly opt in headers with context-enabled primitives. With this in place, we can start enabling the analysis on more complex subsystems in subsequent changes. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251219154418.3592607-26-elver@google.com
2026-01-05compiler-context-analysis: Remove __cond_lock() function-like helperMarco Elver24-195/+163
As discussed in [1], removing __cond_lock() will improve the readability of trylock code. Now that Sparse context tracking support has been removed, we can also remove __cond_lock(). Change existing APIs to either drop __cond_lock() completely, or make use of the __cond_acquires() function attribute instead. In particular, spinlock and rwlock implementations required switching over to inline helpers rather than statement-expressions for their trylock_* variants. 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/20250207082832.GU7145@noisy.programming.kicks-ass.net/ [1] Link: https://patch.msgid.link/20251219154418.3592607-25-elver@google.com
2026-01-05compiler-context-analysis: Remove Sparse supportMarco Elver3-91/+28
Remove Sparse support as discussed at [1]. The kernel codebase is still scattered with numerous places that try to appease Sparse's context tracking ("annotation for sparse", "fake out sparse", "work around sparse", etc.). Eventually, as more subsystems enable Clang's context analysis, these places will show up and need adjustment or removal of the workarounds altogether. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/all/20250207083335.GW7145@noisy.programming.kicks-ass.net/ [1] Link: https://lore.kernel.org/all/Z6XTKTo_LMj9KmbY@elver.google.com/ [2] Link: https://patch.msgid.link/20251219154418.3592607-24-elver@google.com
2026-01-05um: Fix incorrect __acquires/__releases annotationsMarco Elver2-7/+11
With Clang's context analysis, the compiler is a bit more strict about what goes into the __acquires/__releases annotations and can't refer to non-existent variables. On an UM build, mm_id.h is transitively included into mm_types.h, and we can observe the following error (if context analysis is enabled in e.g. stackdepot.c): In file included from lib/stackdepot.c:17: In file included from include/linux/debugfs.h:15: In file included from include/linux/fs.h:5: In file included from include/linux/fs/super.h:5: In file included from include/linux/fs/super_types.h:7: In file included from include/linux/list_lru.h:14: In file included from include/linux/xarray.h:16: In file included from include/linux/gfp.h:7: In file included from include/linux/mmzone.h:22: In file included from include/linux/mm_types.h:26: In file included from arch/um/include/asm/mmu.h:12: >> arch/um/include/shared/skas/mm_id.h:24:54: error: use of undeclared identifier 'turnstile' 24 | void enter_turnstile(struct mm_id *mm_id) __acquires(turnstile); | ^~~~~~~~~ arch/um/include/shared/skas/mm_id.h:25:53: error: use of undeclared identifier 'turnstile' 25 | void exit_turnstile(struct mm_id *mm_id) __releases(turnstile); | ^~~~~~~~~ One (discarded) option was to use token_context_lock(turnstile) to just define a token with the already used name, but that would not allow the compiler to distinguish between different mm_id-dependent instances. Another constraint is that struct mm_id is only declared and incomplete in the header, so even if we tried to construct an expression to get to the mutex instance, this would fail (including more headers transitively everywhere should also be avoided). Instead, just declare an mm_id-dependent helper to return the mutex, and use the mm_id-dependent call expression in the __acquires/__releases attributes; the compiler will consider the identity of the mutex to be the call expression. Then using __get_turnstile() in the lock/unlock wrappers (with context analysis enabled for mmu.c) the compiler will be able to verify the implementation of the wrappers as-is. We leave context analysis disabled in arch/um/kernel/skas/ for now. This change is a preparatory change to allow enabling context analysis in subsystems that include any of the above headers. No functional change intended. Closes: https://lore.kernel.org/oe-kbuild-all/202512171220.vHlvhpCr-lkp@intel.com/ Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251219154418.3592607-23-elver@google.com
2026-01-05debugfs: Make debugfs_cancellation a context lock structMarco Elver1-7/+5
When compiling include/linux/debugfs.h with CONTEXT_ANALYSIS enabled, we can see this error: ./include/linux/debugfs.h:239:17: error: use of undeclared identifier 'cancellation' 239 | void __acquires(cancellation) Move the __acquires(..) attribute after the declaration, so that the compiler can see the cancellation function argument, as well as making struct debugfs_cancellation a real context lock to benefit from Clang's context analysis. This change is a preparatory change to allow enabling context analysis in subsystems that include the above header. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Link: https://patch.msgid.link/20251219154418.3592607-22-elver@google.com
2026-01-05locking/ww_mutex: Support Clang's context analysisMarco Elver3-7/+87
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 Elver4-36/+161
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/local_lock: Include missing headersMarco Elver1-0/+2
Including <linux/local_lock.h> into an empty TU will result in the compiler complaining: ./include/linux/local_lock.h: In function ‘class_local_lock_irqsave_constructor’: ./include/linux/local_lock_internal.h:95:17: error: implicit declaration of function ‘local_irq_save’; <...> 95 | local_irq_save(flags); \ | ^~~~~~~~~~~~~~ As well as (some architectures only, such as 'sh'): ./include/linux/local_lock_internal.h: In function ‘local_lock_acquire’: ./include/linux/local_lock_internal.h:33:20: error: ‘current’ undeclared (first use in this function) 33 | l->owner = current; Include missing headers to allow including local_lock.h where the required headers are not otherwise included. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Link: https://patch.msgid.link/20251219154418.3592607-19-elver@google.com
2026-01-05locking/rwsem: Support Clang's context analysisMarco Elver3-28/+114
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-05kref: Add context-analysis annotationsMarco Elver1-0/+2
Mark functions that conditionally acquire the passed lock. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Link: https://patch.msgid.link/20251219154418.3592607-17-elver@google.com
2026-01-05srcu: Support Clang's context analysisMarco Elver5-25/+91
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 Elver3-25/+139
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 Elver4-5/+48
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-05bit_spinlock: Include missing <asm/processor.h>Marco Elver1-0/+2
Including <linux/bit_spinlock.h> into an empty TU will result in the compiler complaining: ./include/linux/bit_spinlock.h:34:4: error: call to undeclared function 'cpu_relax'; <...> 34 | cpu_relax(); | ^ 1 error generated. Include <asm/processor.h> to allow including bit_spinlock.h where <asm/processor.h> is not otherwise included. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Link: https://patch.msgid.link/20251219154418.3592607-13-elver@google.com
2026-01-05locking/seqlock: Support Clang's context analysisMarco Elver4-4/+91
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 Elver4-18/+90
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-05compiler-context-analysis: Change __cond_acquires to take return valueMarco Elver6-17/+38
While Sparse is oblivious to the return value of conditional acquire functions, Clang's context analysis needs to know the return value which indicates successful acquisition. Add the additional argument, and convert existing uses. Notably, Clang's interpretation of the value merely relates to the use in a later conditional branch, i.e. 1 ==> context lock acquired in branch taken if condition non-zero, and 0 ==> context lock acquired in branch taken if condition is zero. Given the precise value does not matter, introduce symbolic variants to use instead of either 0 or 1, which should be more intuitive. No functional change 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-10-elver@google.com
2026-01-05locking/rwlock, spinlock: Support Clang's context analysisMarco Elver12-97/+347
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
generated by cgit v1.2.3 (git 2.39.0) at 2026-05-03 09:49:24 +0300