locking updates for v6.20

Linus,

Please pull the latest locking/core Git tree from:

git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking-core-2026-02-08

for you to fetch changes up to 7a562d5d2396c9c78fbbced7ae81bcfcfa0fde3f:

[ MERGE NOTE: please note the default-enabled nature of the new
locking context analysis feature, and its justification described below. If that's too aggressive, please disregard this pull request. ]

Locking updates for v6.20:

Lock debugging:

- Implement compiler-driven static analysis locking context checking, using the upcoming Clang 22 compiler's context analysis features. (Marco Elver)

We removed Sparse context analysis support, because prior to removal even a defconfig kernel produced 1,700+ context tracking Sparse warnings, the overwhelming majority of which are false positives. On an allmodconfig kernel the number of false positive context tracking Sparse warnings grows to over 5,200... On the plus side of the balance actual locking bugs found by Sparse context analysis is also rather ... sparse:
I found only 3 such commits in the last 3 years. So the rate of false positives and the maintenance overhead is rather high and there appears to be no active policy in place to achieve a zero-warnings baseline to move the annotations & fixers to developers who introduce new code.

Clang context analysis is more complete and more aggressive in trying to find bugs, at least in principle. Plus it has a different model to enabling it: it's enabled subsystem by subsystem, which results in zero warnings on all relevant kernel builds (as far as our testing managed to cover it). Which allowed us to enable it by default, similar to other compiler warnings, with the expectation that there are no warnings going forward. This enforces a zero-warnings baseline on clang-22+ builds. (Which are still limited in distribution, admittedly.)

Hopefully the Clang approach can lead to a more maintainable zero-warnings status quo and policy, with more and more subsystems and drivers enabling the feature. Context tracking can be enabled for all kernel code via WARN_CONTEXT_ANALYSIS_ALL=y (default disabled), but this will generate a lot of false positives.

( Having said that, Sparse support could still be added back,
if anyone is interested - the removal patch is still relatively straightforward to revert at this stage. )

Rust integration updates: (Alice Ryhl, Fujita Tomonori, Boqun Feng)

- Add support for Atomic<i8/i16/bool> and replace most Rust native AtomicBool usages with Atomic<bool>

- Clean up LockClassKey and improve its documentation

- Add missing Send and Sync trait implementation for SetOnce

- Make ARef Unpin as it is supposed to be

- Add __rust_helper to a few Rust helpers as a preparation for helper LTO

- Inline various lock related functions to avoid additional function calls.

WW mutexes:

- Extend ww_mutex tests and other test-ww_mutex updates (John Stultz)

Misc fixes and cleanups:

- rcu: Mark lockdep_assert_rcu_helper() __always_inline (Arnd Bergmann)

- locking/local_lock: Include more missing headers (Peter Zijlstra)

- seqlock: fix scoped_seqlock_read kernel-doc (Randy Dunlap)

- rust: sync: Replace kernel::c_str! with C-Strings (Tamir Duberstein)

Thanks,

Ingo

------------------>
Alice Ryhl (16):
rust: sync: Refactor static_lock_class!() macro
rust: sync: Clean up LockClassKey and its docs
rust: sync: Implement Unpin for ARef
rust: barrier: Add __rust_helper to helpers
rust: blk: Add __rust_helper to helpers
rust: completion: Add __rust_helper to helpers
rust: cpu: Add __rust_helper to helpers
rust: processor: Add __rust_helper to helpers
rust: rcu: Add __rust_helper to helpers
rust: refcount: Add __rust_helper to helpers
rust: sync: Add __rust_helper to helpers
rust: task: Add __rust_helper to helpers
rust: time: Add __rust_helper to helpers
rust: wait: Add __rust_helper to helpers
rust: helpers: Move #define __rust_helper out of atomic.c
rust: sync: Inline various lock related methods

Arnd Bergmann (1):
rcu: Mark lockdep_assert_rcu_helper() __always_inline

Boqun Feng (1):
arch: um/x86: Select ARCH_SUPPORTS_ATOMIC_RMW for UML_X86

FUJITA Tomonori (19):
rust: sync: set_once: Implement Send and Sync
rust: helpers: Add i8/i16 atomic_read_acquire/atomic_set_release helpers
rust: helpers: Add i8/i16 relaxed atomic helpers
rust: helpers: Add i8/i16 atomic xchg helpers
rust: helpers: Add i8/i16 atomic xchg_acquire helpers
rust: helpers: Add i8/i16 atomic xchg_release helpers
rust: helpers: Add i8/i16 atomic xchg_relaxed helpers
rust: helpers: Add i8/i16 atomic try_cmpxchg helpers
rust: helpers: Add i8/i16 atomic try_cmpxchg_acquire helpers
rust: helpers: Add i8/i16 atomic try_cmpxchg_release helpers
rust: helpers: Add i8/i16 atomic try_cmpxchg_relaxed helpers
rust: sync: atomic: Prepare AtomicOps macros for i8/i16 support
rust: sync: atomic: Add i8/i16 load and store support
rust: sync: atomic: Add store_release/load_acquire tests
rust: sync: atomic: Add i8/i16 xchg and cmpxchg support
rust: sync: atomic: Add atomic bool support via i8 representation
rust: sync: atomic: Add atomic bool tests
rust: list: Switch to kernel::sync atomic primitives
rust_binder: Switch to kernel::sync atomic primitives

John Stultz (3):
test-ww_mutex: Extend ww_mutex tests to test both classes of ww_mutexes
test-ww_mutex: Move work to its own UNBOUND workqueue
test-ww_mutex: Allow test to be run (and re-run) from userland

Marco Elver (45):
compiler_types: Move lock checking attributes to compiler-context-analysis.h
compiler-context-analysis: Add infrastructure for Context Analysis with Clang
compiler-context-analysis: Add test stub
Documentation: Add documentation for Compiler-Based Context Analysis
checkpatch: Warn about context_unsafe() without comment
cleanup: Basic compatibility with context analysis
lockdep: Annotate lockdep assertions for context analysis locking/rwlock, spinlock: Support Clang's context analysis
compiler-context-analysis: Change __cond_acquires to take return value locking/mutex: Support Clang's context analysis
locking/seqlock: Support Clang's context analysis
bit_spinlock: Include missing <asm/processor.h>
bit_spinlock: Support Clang's context analysis
rcu: Support Clang's context analysis
srcu: Support Clang's context analysis
kref: Add context-analysis annotations
locking/rwsem: Support Clang's context analysis locking/local_lock: Include missing headers
locking/local_lock: Support Clang's context analysis locking/ww_mutex: Support Clang's context analysis
debugfs: Make debugfs_cancellation a context lock struct
um: Fix incorrect __acquires/__releases annotations
compiler-context-analysis: Remove Sparse support
compiler-context-analysis: Remove __cond_lock() function-like helper
compiler-context-analysis: Introduce header suppressions
compiler: Let data_race() imply disabled context analysis
MAINTAINERS: Add entry for Context Analysis
kfence: Enable context analysis
kcov: Enable context analysis
kcsan: Enable context analysis
stackdepot: Enable context analysis
rhashtable: Enable context analysis
printk: Move locking annotation to printk.c
security/tomoyo: Enable context analysis
crypto: Enable context analysis
sched: Enable context analysis for core.c and fair.c
compiler-context-analysys: Fix CONFIG_MODVERSION
tools: Update context analysis macros in compiler_types.h
cleanup: Make __DEFINE_LOCK_GUARD handle commas in initializers
compiler-context-analysis: Introduce scoped init guards
kcov: Use scoped init guard
crypto: Use scoped init guard
tomoyo: Use scoped init guard
compiler-context-analysis: Remove __assume_ctx_lock from initializers locking/rwlock: Fix write_trylock_irqsave() with CONFIG_INLINE_WRITE_TRYLOCK

Peter Zijlstra (2):
tags: Add regex for context_lock_struct locking/local_lock: Include more missing headers

Randy Dunlap (1):
seqlock: fix scoped_seqlock_read kernel-doc

Tamir Duberstein (1):
rust: sync: Replace kernel::c_str! with C-Strings

oldzhu (1):
scripts/atomic: Fix kerneldoc spelling in try_cmpxchg()

 Documentation/dev-tools/context-analysis.rst       | 169 ++++++
 Documentation/dev-tools/index.rst                  |   1 +
 Documentation/dev-tools/sparse.rst                 |  19 -
 Documentation/mm/process_addrs.rst                 |   6 +-
 MAINTAINERS                                        |  11 +
 Makefile                                           |   1 +
 arch/um/include/shared/skas/mm_id.h                |   5 +-
 arch/um/kernel/skas/mmu.c                          |  13 +-
 arch/x86/um/Kconfig                                |   1 +
 crypto/Makefile                                    |   2 +
 crypto/acompress.c                                 |   6 +-
 crypto/algapi.c                                    |   2 +
 crypto/api.c                                       |   1 +
 crypto/crypto_engine.c                             |   2 +-
 crypto/drbg.c                                      |   7 +-
 crypto/internal.h                                  |   2 +-
 crypto/proc.c                                      |   3 +
 crypto/scompress.c                                 |  24 +-
 drivers/android/binder/rust_binder_main.rs         |  20 +-
 drivers/android/binder/stats.rs                    |   8 +-
 drivers/android/binder/thread.rs                   |  24 +-
 drivers/android/binder/transaction.rs              |  16 +-
 drivers/net/wireless/intel/iwlwifi/iwl-trans.c     |   4 +-
 drivers/net/wireless/intel/iwlwifi/iwl-trans.h     |   6 +-
 .../wireless/intel/iwlwifi/pcie/gen1_2/internal.h  |   5 +-
 .../net/wireless/intel/iwlwifi/pcie/gen1_2/trans.c |   4 +-
 fs/dlm/lock.c                                      |   2 +-
 include/crypto/internal/acompress.h                |   7 +-
 include/crypto/internal/engine.h                   |   2 +-
 include/linux/atomic/atomic-arch-fallback.h        |  18 +-
 include/linux/atomic/atomic-instrumented.h         |  26 +-
 include/linux/atomic/atomic-long.h                 |  10 +-
 include/linux/bit_spinlock.h                       |  24 +-
 include/linux/cleanup.h                            |  58 +-
 include/linux/compiler-context-analysis.h          | 436 +++++++++++++++
 include/linux/compiler.h                           |   2 +
 include/linux/compiler_types.h                     |  18 +-
 include/linux/console.h                            |   4 +-
 include/linux/debugfs.h                            |  12 +-
 include/linux/kref.h                               |   2 +
 include/linux/list_bl.h                            |   2 +
 include/linux/local_lock.h                         |  59 +-
 include/linux/local_lock_internal.h                |  72 ++-
 include/linux/lockdep.h                            |  12 +-
 include/linux/lockref.h                            |   4 +-
 include/linux/mm.h                                 |  33 +-
 include/linux/mutex.h                              |  40 +-
 include/linux/mutex_types.h                        |   4 +-
 include/linux/rcupdate.h                           |  90 ++--
 include/linux/refcount.h                           |   6 +-
 include/linux/rhashtable.h                         |  16 +-
 include/linux/rwlock.h                             |  19 +-
 include/linux/rwlock_api_smp.h                     |  43 +-
 include/linux/rwlock_rt.h                          |  43 +-
 include/linux/rwlock_types.h                       |  10 +-
 include/linux/rwsem.h                              |  78 ++-
 include/linux/sched.h                              |   6 +-
 include/linux/sched/signal.h                       |  16 +-
 include/linux/sched/task.h                         |   6 +-
 include/linux/sched/wake_q.h                       |   3 +
 include/linux/seqlock.h                            |  57 +-
 include/linux/seqlock_types.h                      |   5 +-
 include/linux/spinlock.h                           | 119 ++--
 include/linux/spinlock_api_smp.h                   |  34 +-
 include/linux/spinlock_api_up.h                    | 112 ++--
 include/linux/spinlock_rt.h                        |  36 +-
 include/linux/spinlock_types.h                     |  10 +-
 include/linux/spinlock_types_raw.h                 |   5 +-
 include/linux/srcu.h                               |  73 ++-
 include/linux/srcutiny.h                           |   6 +
 include/linux/srcutree.h                           |  10 +-
 include/linux/ww_mutex.h                           |  21 +-
 kernel/Makefile                                    |   2 +
 kernel/kcov.c                                      |  36 +-
 kernel/kcsan/Makefile                              |   2 +
 kernel/kcsan/report.c                              |  11 +-
 kernel/locking/test-ww_mutex.c                     | 165 ++++--
 kernel/printk/printk.c                             |   2 +
 kernel/sched/Makefile                              |   3 +
 kernel/sched/core.c                                |  89 ++-
 kernel/sched/fair.c                                |   7 +-
 kernel/sched/sched.h                               | 126 +++--
 kernel/signal.c                                    |   4 +-
 kernel/time/posix-timers.c                         |  13 +-
 lib/Kconfig.debug                                  |  44 ++
 lib/Makefile                                       |   6 +
 lib/dec_and_lock.c                                 |   8 +-
 lib/lockref.c                                      |   1 -
 lib/rhashtable.c                                   |   5 +-
 lib/stackdepot.c                                   |  20 +-
 lib/test_context-analysis.c                        | 598 +++++++++++++++++++++
 mm/kfence/Makefile                                 |   2 +
 mm/kfence/core.c                                   |  20 +-
 mm/kfence/kfence.h                                 |  14 +-
 mm/kfence/report.c                                 |   4 +-
 mm/memory.c                                        |   4 +-
 mm/pgtable-generic.c                               |  19 +-
 net/ipv4/tcp_sigpool.c                             |   2 +-
 rust/helpers/atomic.c                              |   7 +-
 rust/helpers/atomic_ext.c                          | 139 +++++
 rust/helpers/barrier.c                             |   6 +-
 rust/helpers/blk.c                                 |   4 +-
 rust/helpers/completion.c                          |   2 +-
 rust/helpers/cpu.c                                 |   2 +-
 rust/helpers/helpers.c                             |   3 +
 rust/helpers/mutex.c                               |  13 +-
 rust/helpers/processor.c                           |   2 +-
 rust/helpers/rcu.c                                 |   4 +-
 rust/helpers/refcount.c                            |  10 +-
 rust/helpers/signal.c                              |   2 +-
 rust/helpers/spinlock.c                            |  13 +-
 rust/helpers/sync.c                                |   4 +-
 rust/helpers/task.c                                |  24 +-
 rust/helpers/time.c                                |  14 +-
 rust/helpers/wait.c                                |   2 +-
 rust/kernel/list/arc.rs                            |  14 +-
 rust/kernel/sync.rs                                |  73 ++-
 rust/kernel/sync/aref.rs                           |   3 +
 rust/kernel/sync/atomic/internal.rs                | 114 +++-
 rust/kernel/sync/atomic/predefine.rs               |  55 +-
 rust/kernel/sync/lock.rs                           |   7 +
 rust/kernel/sync/lock/global.rs                    |   2 +
 rust/kernel/sync/lock/mutex.rs                     |   5 +
 rust/kernel/sync/lock/spinlock.rs                  |   5 +
 rust/kernel/sync/set_once.rs                       |   8 +
 scripts/Makefile.context-analysis                  |  11 +
 scripts/Makefile.lib                               |  10 +
 scripts/atomic/gen-rust-atomic-helpers.sh          |   5 -
 scripts/atomic/kerneldoc/try_cmpxchg               |   2 +-
 scripts/checkpatch.pl                              |   7 +
 scripts/context-analysis-suppression.txt           |  33 ++
 scripts/tags.sh                                    |   1 +
 security/tomoyo/Makefile                           |   2 +
 security/tomoyo/common.c                           |  54 +-
 security/tomoyo/common.h                           |  77 +--
 security/tomoyo/domain.c                           |   1 +
 security/tomoyo/environ.c                          |   1 +
 security/tomoyo/file.c                             |   5 +
 security/tomoyo/gc.c                               |  28 +-
 security/tomoyo/mount.c                            |   2 +
 security/tomoyo/network.c                          |   3 +
 tools/include/linux/compiler-context-analysis.h    |  42 ++
 tools/include/linux/compiler_types.h               |  18 +-
 tools/testing/shared/linux/kernel.h                |   4 -
 144 files changed, 3222 insertions(+), 861 deletions(-)
 create mode 100644 Documentation/dev-tools/context-analysis.rst
 create mode 100644 include/linux/compiler-context-analysis.h
 create mode 100644 lib/test_context-analysis.c
 create mode 100644 rust/helpers/atomic_ext.c
 create mode 100644 scripts/Makefile.context-analysis
 create mode 100644 scripts/context-analysis-suppression.txt
 create mode 100644 tools/include/linux/compiler-context-analysis.h

Hi Nathan,

See below - Clang's -Wthread-safety support was merged.

I'm not too familiar with ClangBuiltLinux testing and regression testing setups; but I wanted to check if LLVM 'main' is being continuously tested somewhere? I know the Intel test robot takes a ~1-2 week old snapshot of LLVM 'main' and tests that.

Basically I want to ensure that we're able to catch -Wthread-safety regressions on the Clang side that affect the kernel. While I've been adding more and more tests to the LLVM repo for the rather special patterns we decided to use in the kernel to make Context Analysis work, maybe some slipped through the cracks.

E.g. I've been reviewing
https://github.com/llvm/llvm-project/pull/178952 and tested it, too, I'm only 99% certain that PR is ok -- being able to quickly catch a newly introduced issue before waiting for the Intel test robot to start spamming us would be good.

I recall there was a CI system that did this, but lost track of what's the latest.

Thanks,
-- Marco

---------- Forwarded message ---------
From: <[email protected]>
Date: Tue, 10 Feb 2026 at 23:05
Subject: Re: [GIT PULL] locking updates for v6.20
To: Ingo Molnar <[email protected]>
Cc: Linus Torvalds <[email protected]>, <[email protected]>, Peter Zijlstra <[email protected]>, Thomas Gleixner <[email protected]>, Will Deacon <[email protected]>, Waiman Long <[email protected]>, Boqun Feng <[email protected]>, Borislav Petkov <[email protected]>, Uros Bizjak <[email protected]>, Sebastian Andrzej Siewior <[email protected]>, Gary Guo <[email protected]>, Oleg Nesterov <[email protected]>, Marco Elver <[email protected]>

The pull request you sent on Sun, 8 Feb 2026 11:02:19 +0100:

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0923fd0419a1a2c8846e15deacac11b619e996d9

Thank you!

--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

I think you may be referring to
https://github.com/ClangBuiltLinux/continuous-integration2.

By the way, some time ago I asked Aaron (Cc'd) whether we could get the kernel into upstream LLVM's CI system, i.e. to at least build a minimal kernel configuration of a fixed, tagged release for one or two architectures. Would that help you?

(I also suggested Jose (Cc'd) the same, for GCC.)

The idea is that it helps both sides. It serves to catch issues very early on (including with subtle things like diagnostics), and thus avoids having to play catch up later to fix them (compiler) and/or workaround them (kernel) in either side.

To be clear, this wouldn't replace the other CIs that run out of tree, like Nathan's and the tests I do for Rust stuff etc., i.e. it is not about catching every compiler issue or testing the kernel as a product.

For context, this all happened because I asked the same to upstream Rust and it was a success there. In that case, the goal was to catch issues early with the unstable features we use, but it helps with other things too, and thus I think it would help just the same for Clang and GCC. So far, we only got pinged a few times, so it has not been a lot of work, and it did catch a couple issues (which sometimes may end with a preemptive kernel patch or fixing the upstream PR).

We also did it for upstream bindgen, and hopefully it will happen for rustc_codegen_gcc (currently we have an out-of-tree one) and GCC Rust eventually.

Anyway, this is a bit of a tangent, but I thought I could raise it up again and see what comes out of it...

Cheers,
Miguel

Indeed.

It has always been on my backburner to try and get a build of the Linux kernel as part of LLVM's continuous integration but I have never had the time to sit down and interface with folks to see what exactly that entails (I figured it would involve integration with LLVM's build bot infrastructure but I have not dug in super hard to the documentation). An arm64 and x86_64 defconfig build would probably catch quite a bit of initial breakage and it would be easy to pin Linux's version and only bump it when thoroughly tested.

Cheers,
Nathan

FWIW, I continue to be in full support of adding post-commit CI resources for testing Linux kernel needs. I'm not super familiar with the infrastructure side of things, but I'm happy to help make connections with the folks who do know if it's of help.

~Aaron

Yes, I would greatly appreciate that! I would like to see what it would entail in full, as I could potentially carve out some time this quarter or next to actually get it going since it would be beneficial for both sides.

Cheers,
Nathan

Thanks Aaron. Like Nathan, if you could keep me in the loop, that would be great!

By the way, the Rust and bindgen cases are a pre-merge CI, i.e. PRs do not get merged if it fails to build. Post-commit is good too, but I mention it because the Rust one shows it is possible to do even pre-merge without being a big hassle to compiler developers.

Relatedly, by chance, just a few hours ago there has been a PR in upstream Rust for a compiler bug fix that only the Linux kernel CI job exercised -- apparently not a single one of 1832 open source crates tested exercised the bug. So it shows the kernel is quite a good test case ;)

Cheers,
Miguel

Hi Marco,

Congratulations :) I am happy to hear that it has gotten across the finish line and I look forward to more people trying it out.

Yes, it is (at the repository that Miguel pointed out):

https://github.com/ClangBuiltLinux/continuous-integration2/actions/workflows/mainline-clang-23.yml

You can see our full matrix on the ClangBuiltLinux homepage:

https://ClangBuiltLinux.github.io

We rely on apt.llvm.org for the nightly builds, which are normally updated every few days but it was down for a little over a month because of the 22 to 23 transition (if I understand correctly). I actually need to chase that transition in TuxMake.

I also have a testing framework I use for local validation of LLVM main, so I should be able to flag issues fairly quickly:

https://github.com/nathanchance/llvm-kernel-testing

For what it's worth, I have a decent amount of local computing resources so if you ever want a pull request explicitly tested, ping me on it and I am happy to put it through my tests, which should flag any major problems because the context analysis warnings are default on in Kconfig.

Aside from our CI and Intel's, I know Linaro's toolchain group has some testing of LLVM main that seems to be fairly up to date:

https://lore.kernel.org/llvm/?q=f%3Aci_notify%40linaro.org

Cheers,
Nathan

On Wed, 11 Feb 2026 at 20:40, Nathan Chancellor <[email protected]> wrote:
[...]

Thanks, that's what I was looking for.

[..]

Thanks. I'd have said try
https://github.com/llvm/llvm-project/pull/178952, but I think we don't have enough CONTEXT_ANALYSIS:=y coverage yet to find anything (I tested it). Bart found some unrelated crashes, but those have been fixed I think. So yeah, while that's helpful, if 'main' crashes for other reasons, it's hard to pinpoint what's wrong.

Glad to see. I hope that if there are breakages, those are bisected and reported to LLVM PRs that introduced the issues?

But in general, I agree that getting some amount of Linux kernel testing as part of LLVM CI would be helpful to catch regressions in time and avoid the indirection.

Thanks,
-- Marco

Yes, at the very least by myself if not others since those reports are set to the ClangBuiltLinux mailing list.

Cheers,
Nathan