[GIT PULL] locking updates for v6.20

[GIT PULL] locking updates for v6.20

[Ingo Molnar]

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

Re: [GIT PULL] locking updates for v6.20

[pr-tracker-bot]

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

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

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

Clang/LLVM 'main' regression testing and -Wthread-safety

[Marco Elver]

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: <pr-tracker-bot@kernel.org>
Date: Tue, 10 Feb 2026 at 23:05
Subject: Re: [GIT PULL] locking updates for v6.20
To: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
<linux-kernel@vger.kernel.org>, Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>, Will Deacon <will@kernel.org>,
Waiman Long <longman@redhat.com>, Boqun Feng <boqun.feng@gmail.com>,
Borislav Petkov <bp@alien8.de>, Uros Bizjak <ubizjak@gmail.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>, Gary Guo
<gary@garyguo.net>, Oleg Nesterov <oleg@redhat.com>, Marco Elver
<elver@google.com>


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

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

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

Re: Clang/LLVM 'main' regression testing and -Wthread-safety

[Miguel Ojeda]

On Wed, Feb 11, 2026 at 11:59 AM Marco Elver <elver@google.com> wrote:
>
> I recall there was a CI system that did this, but lost track of what's
> the latest.

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

Re: Clang/LLVM 'main' regression testing and -Wthread-safety

[Nathan Chancellor]

Hi Marco,

On Wed, Feb 11, 2026 at 11:58:55AM +0100, Marco Elver wrote:
> See below - Clang's -Wthread-safety support was merged.

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

> 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.

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

> 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.

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.

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

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

Re: Clang/LLVM 'main' regression testing and -Wthread-safety

[Nathan Chancellor]

On Wed, Feb 11, 2026 at 12:54:40PM +0100, Miguel Ojeda wrote:
> On Wed, Feb 11, 2026 at 11:59 AM Marco Elver <elver@google.com> wrote:
> >
> > I recall there was a CI system that did this, but lost track of what's
> > the latest.
> 
> I think you may be referring to
> https://github.com/ClangBuiltLinux/continuous-integration2.

Indeed.

> 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...

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

Re: Clang/LLVM 'main' regression testing and -Wthread-safety

[Marco Elver]

On Wed, 11 Feb 2026 at 20:40, Nathan Chancellor <nathan@kernel.org> wrote:
[...]
> 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

Thanks, that's what I was looking for.

> 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.

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.

> > I recall there was a CI system that did this, but lost track of what's
> > the latest.
>
> 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

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

Re: Clang/LLVM 'main' regression testing and -Wthread-safety

[Aaron Ballman]

On Wed, Feb 11, 2026 at 2:51 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> On Wed, Feb 11, 2026 at 12:54:40PM +0100, Miguel Ojeda wrote:
> > On Wed, Feb 11, 2026 at 11:59 AM Marco Elver <elver@google.com> wrote:
> > >
> > > I recall there was a CI system that did this, but lost track of what's
> > > the latest.
> >
> > I think you may be referring to
> > https://github.com/ClangBuiltLinux/continuous-integration2.
>
> Indeed.
>
> > 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...
>
> 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.

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

>
> Cheers,
> Nathan

Re: Clang/LLVM 'main' regression testing and -Wthread-safety

[Nathan Chancellor]

On Thu, Feb 12, 2026 at 12:53:24AM +0100, Marco Elver wrote:
> On Wed, 11 Feb 2026 at 20:40, Nathan Chancellor <nathan@kernel.org> wrote:
> > > I recall there was a CI system that did this, but lost track of what's
> > > the latest.
> >
> > 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
> 
> Glad to see. I hope that if there are breakages, those are bisected
> and reported to LLVM PRs that introduced the issues?

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

Cheers,
Nathan

Re: Clang/LLVM 'main' regression testing and -Wthread-safety

[Nathan Chancellor]

On Thu, Feb 12, 2026 at 07:22:26AM -0500, Aaron Ballman wrote:
> On Wed, Feb 11, 2026 at 2:51 PM Nathan Chancellor <nathan@kernel.org> wrote:
> > 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.
> 
> 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.

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

Re: Clang/LLVM 'main' regression testing and -Wthread-safety

[Miguel Ojeda]

On Thu, Feb 12, 2026 at 1:22 PM Aaron Ballman <aaron@aaronballman.com> wrote:
>
> 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.

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