* Re: [PATCH tip/locking/core v3] compiler-context-analysis: Bump required Clang version to 23
2026-05-15 12:43 [PATCH tip/locking/core v3] compiler-context-analysis: Bump required Clang version to 23 Marco Elver
@ 2026-05-15 12:50 ` Marco Elver
2026-05-15 15:31 ` Bart Van Assche
` (2 subsequent siblings)
3 siblings, 0 replies; 10+ messages in thread
From: Marco Elver @ 2026-05-15 12:50 UTC (permalink / raw)
To: elver, Peter Zijlstra
Cc: Ingo Molnar, Nathan Chancellor, Nick Desaulniers, Bill Wendling,
Justin Stitt, llvm, Bart Van Assche, linux-kernel
On Fri, 15 May 2026 at 14:44, Marco Elver <elver@google.com> wrote:
>
> Clang 23 introduces several major improvements:
Oh, and in case it wasn't clear, Clang 23 has not yet been released
officially, but the dev version is already used by the Intel test
robot, and preview versions may appear at
https://mirrors.edge.kernel.org/pub/tools/llvm/ (courtesy of Nathan).
The release schedule is on https://llvm.org/: "Tue Aug 25th, 2026: 23.1.0".
> 1. Support for multiple arguments in the `guarded_by` and
> `pt_guarded_by` attributes [1]. This allows defining variables
> protected by multiple context locks, where read access requires
> holding at least one lock (shared or exclusive), and write access
> requires holding all of them exclusively.
>
> 2. Function pointer support [2]. We can now add attributes to function
> pointers just like we do on normal functions.
>
> 3. A fix to use arrays of locks [3]. Each index is now correctly treated
> as a separate lock instance.
>
> 4. A fix for implicit member access in attributes [4]. This allows to
> use __guarded_by(&foo->lock) correctly.
>
> Overall that makes it worthwhile bumping the compiler version instead of
> trying to make both Clang 22 and later work while supporting these new
> features.
>
> Link: https://github.com/llvm/llvm-project/pull/186838 [1]
> Link: https://github.com/llvm/llvm-project/pull/191187 [2]
> Link: https://github.com/llvm/llvm-project/pull/148551 [3]
> Link: https://github.com/llvm/llvm-project/pull/194457 [4]
> Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> Signed-off-by: Marco Elver <elver@google.com>
> ---
> v3:
> * Rebase and update laundry-list of new features and fixes.
>
> v2:
> * Bump version instead of __guarded_by_any workaround.
> ---
> Documentation/dev-tools/context-analysis.rst | 2 +-
> include/linux/compiler-context-analysis.h | 30 ++++++++++++++------
> lib/Kconfig.debug | 4 +--
> lib/test_context-analysis.c | 24 ++++++++++++++++
> 4 files changed, 49 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/dev-tools/context-analysis.rst b/Documentation/dev-tools/context-analysis.rst
> index 54d9ee28de98..8e71e1e75b5b 100644
> --- a/Documentation/dev-tools/context-analysis.rst
> +++ b/Documentation/dev-tools/context-analysis.rst
> @@ -17,7 +17,7 @@ features. To enable for Clang, configure the kernel with::
>
> CONFIG_WARN_CONTEXT_ANALYSIS=y
>
> -The feature requires Clang 22 or later.
> +The feature requires Clang 23 or later.
>
> The analysis is *opt-in by default*, and requires declaring which modules and
> subsystems should be analyzed in the respective `Makefile`::
> diff --git a/include/linux/compiler-context-analysis.h b/include/linux/compiler-context-analysis.h
> index a9317571e6af..8302ebc2ea8c 100644
> --- a/include/linux/compiler-context-analysis.h
> +++ b/include/linux/compiler-context-analysis.h
> @@ -39,12 +39,14 @@
> # define __assumes_shared_ctx_lock(...) __attribute__((assert_shared_capability(__VA_ARGS__)))
>
> /**
> - * __guarded_by - struct member and globals attribute, declares variable
> - * only accessible within active context
> + * __guarded_by() - struct member and globals attribute, declares variable
> + * only accessible within active context
> + * @...: context lock instance pointer(s)
> *
> * Declares that the struct member or global variable is only accessible within
> - * the context entered by the given context lock. Read operations on the data
> - * require shared access, while write operations require exclusive access.
> + * the context entered by the given context lock(s). Read operations on the data
> + * require shared access to at least one of the context locks, while write
> + * operations require exclusive access to all listed context locks.
> *
> * .. code-block:: c
> *
> @@ -52,17 +54,24 @@
> * spinlock_t lock;
> * long counter __guarded_by(&lock);
> * };
> + *
> + * struct some_state {
> + * spinlock_t lock1, lock2;
> + * long counter __guarded_by(&lock1, &lock2);
> + * };
> */
> # define __guarded_by(...) __attribute__((guarded_by(__VA_ARGS__)))
>
> /**
> - * __pt_guarded_by - struct member and globals attribute, declares pointed-to
> - * data only accessible within active context
> + * __pt_guarded_by() - struct member and globals attribute, declares pointed-to
> + * data only accessible within active context
> + * @...: context lock instance pointer(s)
> *
> * Declares that the data pointed to by the struct member pointer or global
> * pointer is only accessible within the context entered by the given context
> - * lock. Read operations on the data require shared access, while write
> - * operations require exclusive access.
> + * lock(s). Read operations on the data require shared access to at least one
> + * of the context locks, while write operations require exclusive access to all
> + * listed context locks.
> *
> * .. code-block:: c
> *
> @@ -70,6 +79,11 @@
> * spinlock_t lock;
> * long *counter __pt_guarded_by(&lock);
> * };
> + *
> + * struct some_state {
> + * spinlock_t lock1, lock2;
> + * long *counter __pt_guarded_by(&lock1, &lock2);
> + * };
> */
> # define __pt_guarded_by(...) __attribute__((pt_guarded_by(__VA_ARGS__)))
>
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 8ff5adcfe1e0..b0f3028a213d 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -630,7 +630,7 @@ config DEBUG_FORCE_WEAK_PER_CPU
>
> config WARN_CONTEXT_ANALYSIS
> bool "Compiler context-analysis warnings"
> - depends on CC_IS_CLANG && CLANG_VERSION >= 220100
> + depends on CC_IS_CLANG && CLANG_VERSION >= 230000
> # Branch profiling re-defines "if", which messes with the compiler's
> # ability to analyze __cond_acquires(..), resulting in false positives.
> depends on !TRACE_BRANCH_PROFILING
> @@ -641,7 +641,7 @@ config WARN_CONTEXT_ANALYSIS
> and releasing user-definable "context locks".
>
> Clang's name of the feature is "Thread Safety Analysis". Requires
> - Clang 22.1.0 or later.
> + Clang 23 or later.
>
> Produces warnings by default. Select CONFIG_WERROR if you wish to
> turn these warnings into errors.
> diff --git a/lib/test_context-analysis.c b/lib/test_context-analysis.c
> index 06b4a6a028e0..316f4dfcda65 100644
> --- a/lib/test_context-analysis.c
> +++ b/lib/test_context-analysis.c
> @@ -159,6 +159,10 @@ TEST_SPINLOCK_COMMON(read_lock,
> struct test_mutex_data {
> struct mutex mtx;
> int counter __guarded_by(&mtx);
> +
> + struct mutex mtx2;
> + int anyread __guarded_by(&mtx, &mtx2);
> + int *anyptr __pt_guarded_by(&mtx, &mtx2);
> };
>
> static void __used test_mutex_init(struct test_mutex_data *d)
> @@ -219,6 +223,26 @@ static void __used test_mutex_cond_guard(struct test_mutex_data *d)
> }
> }
>
> +static void __used test_mutex_multiguard(struct test_mutex_data *d)
> +{
> + mutex_lock(&d->mtx);
> + (void)d->anyread;
> + (void)*d->anyptr;
> + mutex_unlock(&d->mtx);
> +
> + mutex_lock(&d->mtx2);
> + (void)d->anyread;
> + (void)*d->anyptr;
> + mutex_unlock(&d->mtx2);
> +
> + mutex_lock(&d->mtx);
> + mutex_lock(&d->mtx2);
> + d->anyread++;
> + (*d->anyptr)++;
> + mutex_unlock(&d->mtx2);
> + mutex_unlock(&d->mtx);
> +}
> +
> struct test_seqlock_data {
> seqlock_t sl;
> int counter __guarded_by(&sl);
> --
> 2.54.0.563.g4f69b47b94-goog
>
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH tip/locking/core v3] compiler-context-analysis: Bump required Clang version to 23
2026-05-15 12:43 [PATCH tip/locking/core v3] compiler-context-analysis: Bump required Clang version to 23 Marco Elver
2026-05-15 12:50 ` Marco Elver
@ 2026-05-15 15:31 ` Bart Van Assche
2026-05-20 8:28 ` [tip: locking/core] " tip-bot2 for Marco Elver
2026-05-28 10:30 ` tip-bot2 for Marco Elver
3 siblings, 0 replies; 10+ messages in thread
From: Bart Van Assche @ 2026-05-15 15:31 UTC (permalink / raw)
To: Marco Elver, Peter Zijlstra
Cc: Ingo Molnar, Nathan Chancellor, Nick Desaulniers, Bill Wendling,
Justin Stitt, llvm, linux-kernel
On 5/15/26 5:43 AM, Marco Elver wrote:
> Clang 23 introduces several major improvements:
>
> 1. Support for multiple arguments in the `guarded_by` and
> `pt_guarded_by` attributes [1]. This allows defining variables
> protected by multiple context locks, where read access requires
> holding at least one lock (shared or exclusive), and write access
> requires holding all of them exclusively.
>
> 2. Function pointer support [2]. We can now add attributes to function
> pointers just like we do on normal functions.
>
> 3. A fix to use arrays of locks [3]. Each index is now correctly treated
> as a separate lock instance.
>
> 4. A fix for implicit member access in attributes [4]. This allows to
> use __guarded_by(&foo->lock) correctly.
>
> Overall that makes it worthwhile bumping the compiler version instead of
> trying to make both Clang 22 and later work while supporting these new
> features.
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
^ permalink raw reply [flat|nested] 10+ messages in thread
* [tip: locking/core] compiler-context-analysis: Bump required Clang version to 23
2026-05-15 12:43 [PATCH tip/locking/core v3] compiler-context-analysis: Bump required Clang version to 23 Marco Elver
2026-05-15 12:50 ` Marco Elver
2026-05-15 15:31 ` Bart Van Assche
@ 2026-05-20 8:28 ` tip-bot2 for Marco Elver
2026-05-28 9:12 ` Niklas Cassel
2026-05-28 10:30 ` tip-bot2 for Marco Elver
3 siblings, 1 reply; 10+ messages in thread
From: tip-bot2 for Marco Elver @ 2026-05-20 8:28 UTC (permalink / raw)
To: linux-tip-commits
Cc: Marco Elver, Peter Zijlstra (Intel), Nathan Chancellor,
Bart Van Assche, x86, linux-kernel
The following commit has been merged into the locking/core branch of tip:
Commit-ID: 2422e2b10ebb45a6ac7a799a36462bfda3eda4c5
Gitweb: https://git.kernel.org/tip/2422e2b10ebb45a6ac7a799a36462bfda3eda4c5
Author: Marco Elver <elver@google.com>
AuthorDate: Fri, 15 May 2026 14:43:31 +02:00
Committer: Peter Zijlstra <peterz@infradead.org>
CommitterDate: Tue, 19 May 2026 13:49:01 +02:00
compiler-context-analysis: Bump required Clang version to 23
Clang 23 introduces several major improvements:
1. Support for multiple arguments in the `guarded_by` and
`pt_guarded_by` attributes [1]. This allows defining variables
protected by multiple context locks, where read access requires
holding at least one lock (shared or exclusive), and write access
requires holding all of them exclusively.
2. Function pointer support [2]. We can now add attributes to function
pointers just like we do on normal functions.
3. A fix to use arrays of locks [3]. Each index is now correctly treated
as a separate lock instance.
4. A fix for implicit member access in attributes [4]. This allows to
use __guarded_by(&foo->lock) correctly.
Overall that makes it worthwhile bumping the compiler version instead of
trying to make both Clang 22 and later work while supporting these new
features.
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Link: https://github.com/llvm/llvm-project/pull/186838 [1]
Link: https://github.com/llvm/llvm-project/pull/191187 [2]
Link: https://github.com/llvm/llvm-project/pull/148551 [3]
Link: https://github.com/llvm/llvm-project/pull/194457 [4]
Link: https://patch.msgid.link/20260515124426.2227783-1-elver@google.com
---
Documentation/dev-tools/context-analysis.rst | 2 +-
include/linux/compiler-context-analysis.h | 30 +++++++++++++------
lib/Kconfig.debug | 4 +--
lib/test_context-analysis.c | 24 +++++++++++++++-
4 files changed, 49 insertions(+), 11 deletions(-)
diff --git a/Documentation/dev-tools/context-analysis.rst b/Documentation/dev-tools/context-analysis.rst
index 54d9ee2..8e71e1e 100644
--- a/Documentation/dev-tools/context-analysis.rst
+++ b/Documentation/dev-tools/context-analysis.rst
@@ -17,7 +17,7 @@ features. To enable for Clang, configure the kernel with::
CONFIG_WARN_CONTEXT_ANALYSIS=y
-The feature requires Clang 22 or later.
+The feature requires Clang 23 or later.
The analysis is *opt-in by default*, and requires declaring which modules and
subsystems should be analyzed in the respective `Makefile`::
diff --git a/include/linux/compiler-context-analysis.h b/include/linux/compiler-context-analysis.h
index a931757..8302ebc 100644
--- a/include/linux/compiler-context-analysis.h
+++ b/include/linux/compiler-context-analysis.h
@@ -39,12 +39,14 @@
# define __assumes_shared_ctx_lock(...) __attribute__((assert_shared_capability(__VA_ARGS__)))
/**
- * __guarded_by - struct member and globals attribute, declares variable
- * only accessible within active context
+ * __guarded_by() - struct member and globals attribute, declares variable
+ * only accessible within active context
+ * @...: context lock instance pointer(s)
*
* Declares that the struct member or global variable is only accessible within
- * the context entered by the given context lock. Read operations on the data
- * require shared access, while write operations require exclusive access.
+ * the context entered by the given context lock(s). Read operations on the data
+ * require shared access to at least one of the context locks, while write
+ * operations require exclusive access to all listed context locks.
*
* .. code-block:: c
*
@@ -52,17 +54,24 @@
* spinlock_t lock;
* long counter __guarded_by(&lock);
* };
+ *
+ * struct some_state {
+ * spinlock_t lock1, lock2;
+ * long counter __guarded_by(&lock1, &lock2);
+ * };
*/
# define __guarded_by(...) __attribute__((guarded_by(__VA_ARGS__)))
/**
- * __pt_guarded_by - struct member and globals attribute, declares pointed-to
- * data only accessible within active context
+ * __pt_guarded_by() - struct member and globals attribute, declares pointed-to
+ * data only accessible within active context
+ * @...: context lock instance pointer(s)
*
* Declares that the data pointed to by the struct member pointer or global
* pointer is only accessible within the context entered by the given context
- * lock. Read operations on the data require shared access, while write
- * operations require exclusive access.
+ * lock(s). Read operations on the data require shared access to at least one
+ * of the context locks, while write operations require exclusive access to all
+ * listed context locks.
*
* .. code-block:: c
*
@@ -70,6 +79,11 @@
* spinlock_t lock;
* long *counter __pt_guarded_by(&lock);
* };
+ *
+ * struct some_state {
+ * spinlock_t lock1, lock2;
+ * long *counter __pt_guarded_by(&lock1, &lock2);
+ * };
*/
# define __pt_guarded_by(...) __attribute__((pt_guarded_by(__VA_ARGS__)))
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 8ff5adc..b0f3028 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -630,7 +630,7 @@ config DEBUG_FORCE_WEAK_PER_CPU
config WARN_CONTEXT_ANALYSIS
bool "Compiler context-analysis warnings"
- depends on CC_IS_CLANG && CLANG_VERSION >= 220100
+ depends on CC_IS_CLANG && CLANG_VERSION >= 230000
# Branch profiling re-defines "if", which messes with the compiler's
# ability to analyze __cond_acquires(..), resulting in false positives.
depends on !TRACE_BRANCH_PROFILING
@@ -641,7 +641,7 @@ config WARN_CONTEXT_ANALYSIS
and releasing user-definable "context locks".
Clang's name of the feature is "Thread Safety Analysis". Requires
- Clang 22.1.0 or later.
+ Clang 23 or later.
Produces warnings by default. Select CONFIG_WERROR if you wish to
turn these warnings into errors.
diff --git a/lib/test_context-analysis.c b/lib/test_context-analysis.c
index 06b4a6a..316f4df 100644
--- a/lib/test_context-analysis.c
+++ b/lib/test_context-analysis.c
@@ -159,6 +159,10 @@ TEST_SPINLOCK_COMMON(read_lock,
struct test_mutex_data {
struct mutex mtx;
int counter __guarded_by(&mtx);
+
+ struct mutex mtx2;
+ int anyread __guarded_by(&mtx, &mtx2);
+ int *anyptr __pt_guarded_by(&mtx, &mtx2);
};
static void __used test_mutex_init(struct test_mutex_data *d)
@@ -219,6 +223,26 @@ static void __used test_mutex_cond_guard(struct test_mutex_data *d)
}
}
+static void __used test_mutex_multiguard(struct test_mutex_data *d)
+{
+ mutex_lock(&d->mtx);
+ (void)d->anyread;
+ (void)*d->anyptr;
+ mutex_unlock(&d->mtx);
+
+ mutex_lock(&d->mtx2);
+ (void)d->anyread;
+ (void)*d->anyptr;
+ mutex_unlock(&d->mtx2);
+
+ mutex_lock(&d->mtx);
+ mutex_lock(&d->mtx2);
+ d->anyread++;
+ (*d->anyptr)++;
+ mutex_unlock(&d->mtx2);
+ mutex_unlock(&d->mtx);
+}
+
struct test_seqlock_data {
seqlock_t sl;
int counter __guarded_by(&sl);
^ permalink raw reply related [flat|nested] 10+ messages in thread* Re: [tip: locking/core] compiler-context-analysis: Bump required Clang version to 23
2026-05-20 8:28 ` [tip: locking/core] " tip-bot2 for Marco Elver
@ 2026-05-28 9:12 ` Niklas Cassel
2026-05-28 9:37 ` Peter Zijlstra
0 siblings, 1 reply; 10+ messages in thread
From: Niklas Cassel @ 2026-05-28 9:12 UTC (permalink / raw)
To: linux-kernel
Cc: linux-tip-commits, Marco Elver, Peter Zijlstra (Intel),
Nathan Chancellor, Bart Van Assche, x86, dlemoal
On Wed, May 20, 2026 at 08:28:08AM -0000, tip-bot2 for Marco Elver wrote:
> The following commit has been merged into the locking/core branch of tip:
>
> Commit-ID: 2422e2b10ebb45a6ac7a799a36462bfda3eda4c5
> Gitweb: https://git.kernel.org/tip/2422e2b10ebb45a6ac7a799a36462bfda3eda4c5
> Author: Marco Elver <elver@google.com>
> AuthorDate: Fri, 15 May 2026 14:43:31 +02:00
> Committer: Peter Zijlstra <peterz@infradead.org>
> CommitterDate: Tue, 19 May 2026 13:49:01 +02:00
>
> compiler-context-analysis: Bump required Clang version to 23
>
> Clang 23 introduces several major improvements:
>
> 1. Support for multiple arguments in the `guarded_by` and
> `pt_guarded_by` attributes [1]. This allows defining variables
> protected by multiple context locks, where read access requires
> holding at least one lock (shared or exclusive), and write access
> requires holding all of them exclusively.
>
> 2. Function pointer support [2]. We can now add attributes to function
> pointers just like we do on normal functions.
>
> 3. A fix to use arrays of locks [3]. Each index is now correctly treated
> as a separate lock instance.
>
> 4. A fix for implicit member access in attributes [4]. This allows to
> use __guarded_by(&foo->lock) correctly.
>
> Overall that makes it worthwhile bumping the compiler version instead of
> trying to make both Clang 22 and later work while supporting these new
> features.
>
> Signed-off-by: Marco Elver <elver@google.com>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> Reviewed-by: Bart Van Assche <bvanassche@acm.org>
> Link: https://github.com/llvm/llvm-project/pull/186838 [1]
> Link: https://github.com/llvm/llvm-project/pull/191187 [2]
> Link: https://github.com/llvm/llvm-project/pull/148551 [3]
> Link: https://github.com/llvm/llvm-project/pull/194457 [4]
> Link: https://patch.msgid.link/20260515124426.2227783-1-elver@google.com
> ---
Hello Peter,
I can see that this has been queued up on branch: locking/core
However, this branch also has a bunch of other stuff queued up on it.
I would like to queue up a libata patch that requires this patch for
kernel 7.2 in the libata tree:
https://lore.kernel.org/linux-ide/7ce6e1f0-6c65-439f-9a34-92bc5e977cce@suse.de/T/#t
(Without the patch in $subject, implicit member access in attributes does not
work, and the above libata patch would result in build errors on clang 22.)
Would it be possible for you to provide an immutable branch with only
this specific commit, such that I could merge that immutable branch to
libata/for-next (such that we carry the exact same SHA1) in both trees?
That way, the libata patch could be queued up for 7.2.
Otherwise, the libata patch would need to wait to first be included in
kernel 7.3:
the v7.3 kernel predictions: merge window closes on Sunday, 2026-09-13
and release on Sunday, 2026-11-08
An immutable branch would mean that it could make it to v7.2.
Kind regards,
Niklas
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [tip: locking/core] compiler-context-analysis: Bump required Clang version to 23
2026-05-28 9:12 ` Niklas Cassel
@ 2026-05-28 9:37 ` Peter Zijlstra
2026-05-28 10:27 ` Peter Zijlstra
0 siblings, 1 reply; 10+ messages in thread
From: Peter Zijlstra @ 2026-05-28 9:37 UTC (permalink / raw)
To: Niklas Cassel
Cc: linux-kernel, linux-tip-commits, Marco Elver, Nathan Chancellor,
Bart Van Assche, x86, dlemoal
On Thu, May 28, 2026 at 11:12:42AM +0200, Niklas Cassel wrote:
> On Wed, May 20, 2026 at 08:28:08AM -0000, tip-bot2 for Marco Elver wrote:
> > The following commit has been merged into the locking/core branch of tip:
> >
> > Commit-ID: 2422e2b10ebb45a6ac7a799a36462bfda3eda4c5
> > Gitweb: https://git.kernel.org/tip/2422e2b10ebb45a6ac7a799a36462bfda3eda4c5
> > Author: Marco Elver <elver@google.com>
> > AuthorDate: Fri, 15 May 2026 14:43:31 +02:00
> > Committer: Peter Zijlstra <peterz@infradead.org>
> > CommitterDate: Tue, 19 May 2026 13:49:01 +02:00
> >
> > compiler-context-analysis: Bump required Clang version to 23
> >
> > Clang 23 introduces several major improvements:
> >
> > 1. Support for multiple arguments in the `guarded_by` and
> > `pt_guarded_by` attributes [1]. This allows defining variables
> > protected by multiple context locks, where read access requires
> > holding at least one lock (shared or exclusive), and write access
> > requires holding all of them exclusively.
> >
> > 2. Function pointer support [2]. We can now add attributes to function
> > pointers just like we do on normal functions.
> >
> > 3. A fix to use arrays of locks [3]. Each index is now correctly treated
> > as a separate lock instance.
> >
> > 4. A fix for implicit member access in attributes [4]. This allows to
> > use __guarded_by(&foo->lock) correctly.
> >
> > Overall that makes it worthwhile bumping the compiler version instead of
> > trying to make both Clang 22 and later work while supporting these new
> > features.
> >
> > Signed-off-by: Marco Elver <elver@google.com>
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> > Reviewed-by: Bart Van Assche <bvanassche@acm.org>
> > Link: https://github.com/llvm/llvm-project/pull/186838 [1]
> > Link: https://github.com/llvm/llvm-project/pull/191187 [2]
> > Link: https://github.com/llvm/llvm-project/pull/148551 [3]
> > Link: https://github.com/llvm/llvm-project/pull/194457 [4]
> > Link: https://patch.msgid.link/20260515124426.2227783-1-elver@google.com
> > ---
>
> Hello Peter,
>
> I can see that this has been queued up on branch: locking/core
>
> However, this branch also has a bunch of other stuff queued up on it.
>
>
> I would like to queue up a libata patch that requires this patch for
> kernel 7.2 in the libata tree:
> https://lore.kernel.org/linux-ide/7ce6e1f0-6c65-439f-9a34-92bc5e977cce@suse.de/T/#t
>
> (Without the patch in $subject, implicit member access in attributes does not
> work, and the above libata patch would result in build errors on clang 22.)
Yeah, I reported that to Marco a while ago; sadly I did not yet get
around to trying to fix the patch I had with a fresh clang :/
> Would it be possible for you to provide an immutable branch with only
> this specific commit, such that I could merge that immutable branch to
> libata/for-next (such that we carry the exact same SHA1) in both trees?
I think that means I have to rebase tip/locking/core; pull out that
patch and stick it in a separate branch and then merge the two branches,
right? Git and me never really get along well.
Let me see if I can do this without destroying stuff :-)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [tip: locking/core] compiler-context-analysis: Bump required Clang version to 23
2026-05-28 9:37 ` Peter Zijlstra
@ 2026-05-28 10:27 ` Peter Zijlstra
2026-05-28 10:44 ` Niklas Cassel
0 siblings, 1 reply; 10+ messages in thread
From: Peter Zijlstra @ 2026-05-28 10:27 UTC (permalink / raw)
To: Niklas Cassel
Cc: linux-kernel, linux-tip-commits, Marco Elver, Nathan Chancellor,
Bart Van Assche, x86, dlemoal
On Thu, May 28, 2026 at 11:37:22AM +0200, Peter Zijlstra wrote:
> > Would it be possible for you to provide an immutable branch with only
> > this specific commit, such that I could merge that immutable branch to
> > libata/for-next (such that we carry the exact same SHA1) in both trees?
>
> I think that means I have to rebase tip/locking/core; pull out that
> patch and stick it in a separate branch and then merge the two branches,
> right? Git and me never really get along well.
>
> Let me see if I can do this without destroying stuff :-)
So I think I managed; there should now be tip/locking/context with just
the one commit in and tip/locking/core has an extra merge commit.
Bit ugly, but I've no idea if this can be done better.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [tip: locking/core] compiler-context-analysis: Bump required Clang version to 23
2026-05-28 10:27 ` Peter Zijlstra
@ 2026-05-28 10:44 ` Niklas Cassel
2026-05-28 11:15 ` Peter Zijlstra
0 siblings, 1 reply; 10+ messages in thread
From: Niklas Cassel @ 2026-05-28 10:44 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-kernel, linux-tip-commits, Marco Elver, Nathan Chancellor,
Bart Van Assche, x86, dlemoal
On Thu, May 28, 2026 at 12:27:03PM +0200, Peter Zijlstra wrote:
> On Thu, May 28, 2026 at 11:37:22AM +0200, Peter Zijlstra wrote:
>
> > > Would it be possible for you to provide an immutable branch with only
> > > this specific commit, such that I could merge that immutable branch to
> > > libata/for-next (such that we carry the exact same SHA1) in both trees?
> >
> > I think that means I have to rebase tip/locking/core; pull out that
> > patch and stick it in a separate branch and then merge the two branches,
> > right? Git and me never really get along well.
> >
> > Let me see if I can do this without destroying stuff :-)
Hehe :)
It gives me a smile that you can debug intricate scheduler bugs,
but get worried about a simple git rebase :)
>
> So I think I managed; there should now be tip/locking/context with just
> the one commit in and tip/locking/core has an extra merge commit.
>
> Bit ugly, but I've no idea if this can be done better.
It is correct, old locking/core and new locking/core are identical:
$ git diff 43a037d4fa6d tip/locking/core
I don't think it can be done in a nicer way.
(Yes, locking/core could be rebased on top of locking/context,
but I don't think that is nicer, as it would hides things.)
Just to be explicit: I assume that I have your approval to also carry this
single/exact SHA1:
f45c5c4adb27 ("compiler-context-analysis: Bump required Clang version to 23")
in the libata tree, such that it does not matter which pull request Linus
merges first.
Thank you Peter!
Kind regards,
Niklas
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [tip: locking/core] compiler-context-analysis: Bump required Clang version to 23
2026-05-28 10:44 ` Niklas Cassel
@ 2026-05-28 11:15 ` Peter Zijlstra
0 siblings, 0 replies; 10+ messages in thread
From: Peter Zijlstra @ 2026-05-28 11:15 UTC (permalink / raw)
To: Niklas Cassel
Cc: linux-kernel, linux-tip-commits, Marco Elver, Nathan Chancellor,
Bart Van Assche, x86, dlemoal
On Thu, May 28, 2026 at 12:44:02PM +0200, Niklas Cassel wrote:
> On Thu, May 28, 2026 at 12:27:03PM +0200, Peter Zijlstra wrote:
> > On Thu, May 28, 2026 at 11:37:22AM +0200, Peter Zijlstra wrote:
> >
> > > > Would it be possible for you to provide an immutable branch with only
> > > > this specific commit, such that I could merge that immutable branch to
> > > > libata/for-next (such that we carry the exact same SHA1) in both trees?
> > >
> > > I think that means I have to rebase tip/locking/core; pull out that
> > > patch and stick it in a separate branch and then merge the two branches,
> > > right? Git and me never really get along well.
> > >
> > > Let me see if I can do this without destroying stuff :-)
>
> Hehe :)
>
> It gives me a smile that you can debug intricate scheduler bugs,
> but get worried about a simple git rebase :)
Somewhere along the line I have failed to understand something
fundamental about git and it just doesn't want to make sense to me :/
I can mostly get things done, but I'm never confident because of this
misunderstanding, things feel off.
There's things like: A...B, A..B, B..A, B...A for ranges that are all
weirdly different (eg. I would expect A...B to get me the reverse diff
from B...A, but afaiu that is very much not the case, and wtf is the two
dots vs three dots thing anyway), and then there's sha:file but also sha
-- file in random and mysterious ways.
And there is bisection across non linear history, and then I never know
WTF the thing does. Often I end up linearising things and then bisect
that, but this can't be right.
Anyway, I've tried to read the man page, and various random web
ramblings on these things, but it just doesn't want to make sense.
So I stick to mostly using quilt and occasionally touch git when I
absolutely have to, like now.
And actually doing rebases with conflicts is the absolute worst possible
thing. I often just pull the patches from git, rebase using quilt and
then re-commit. Git is just actively making that the most painful
experience ever.
Anyway, that's my rant done, sorry about that :-)
> Just to be explicit: I assume that I have your approval to also carry this
> single/exact SHA1:
> f45c5c4adb27 ("compiler-context-analysis: Bump required Clang version to 23")
Yes, that was the whole point of this exercise after all.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [tip: locking/core] compiler-context-analysis: Bump required Clang version to 23
2026-05-15 12:43 [PATCH tip/locking/core v3] compiler-context-analysis: Bump required Clang version to 23 Marco Elver
` (2 preceding siblings ...)
2026-05-20 8:28 ` [tip: locking/core] " tip-bot2 for Marco Elver
@ 2026-05-28 10:30 ` tip-bot2 for Marco Elver
3 siblings, 0 replies; 10+ messages in thread
From: tip-bot2 for Marco Elver @ 2026-05-28 10:30 UTC (permalink / raw)
To: linux-tip-commits
Cc: Marco Elver, Peter Zijlstra (Intel), Nathan Chancellor,
Bart Van Assche, x86, linux-kernel
The following commit has been merged into the locking/core branch of tip:
Commit-ID: f45c5c4adb27540d43302155e2fbaeca6c3c6d03
Gitweb: https://git.kernel.org/tip/f45c5c4adb27540d43302155e2fbaeca6c3c6d03
Author: Marco Elver <elver@google.com>
AuthorDate: Fri, 15 May 2026 14:43:31 +02:00
Committer: Peter Zijlstra <peterz@infradead.org>
CommitterDate: Thu, 28 May 2026 12:20:19 +02:00
compiler-context-analysis: Bump required Clang version to 23
Clang 23 introduces several major improvements:
1. Support for multiple arguments in the `guarded_by` and
`pt_guarded_by` attributes [1]. This allows defining variables
protected by multiple context locks, where read access requires
holding at least one lock (shared or exclusive), and write access
requires holding all of them exclusively.
2. Function pointer support [2]. We can now add attributes to function
pointers just like we do on normal functions.
3. A fix to use arrays of locks [3]. Each index is now correctly treated
as a separate lock instance.
4. A fix for implicit member access in attributes [4]. This allows to
use __guarded_by(&foo->lock) correctly.
Overall that makes it worthwhile bumping the compiler version instead of
trying to make both Clang 22 and later work while supporting these new
features.
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Link: https://github.com/llvm/llvm-project/pull/186838 [1]
Link: https://github.com/llvm/llvm-project/pull/191187 [2]
Link: https://github.com/llvm/llvm-project/pull/148551 [3]
Link: https://github.com/llvm/llvm-project/pull/194457 [4]
Link: https://patch.msgid.link/20260515124426.2227783-1-elver@google.com
---
Documentation/dev-tools/context-analysis.rst | 2 +-
include/linux/compiler-context-analysis.h | 30 +++++++++++++------
lib/Kconfig.debug | 4 +--
lib/test_context-analysis.c | 24 +++++++++++++++-
4 files changed, 49 insertions(+), 11 deletions(-)
diff --git a/Documentation/dev-tools/context-analysis.rst b/Documentation/dev-tools/context-analysis.rst
index 54d9ee2..8e71e1e 100644
--- a/Documentation/dev-tools/context-analysis.rst
+++ b/Documentation/dev-tools/context-analysis.rst
@@ -17,7 +17,7 @@ features. To enable for Clang, configure the kernel with::
CONFIG_WARN_CONTEXT_ANALYSIS=y
-The feature requires Clang 22 or later.
+The feature requires Clang 23 or later.
The analysis is *opt-in by default*, and requires declaring which modules and
subsystems should be analyzed in the respective `Makefile`::
diff --git a/include/linux/compiler-context-analysis.h b/include/linux/compiler-context-analysis.h
index a931757..8302ebc 100644
--- a/include/linux/compiler-context-analysis.h
+++ b/include/linux/compiler-context-analysis.h
@@ -39,12 +39,14 @@
# define __assumes_shared_ctx_lock(...) __attribute__((assert_shared_capability(__VA_ARGS__)))
/**
- * __guarded_by - struct member and globals attribute, declares variable
- * only accessible within active context
+ * __guarded_by() - struct member and globals attribute, declares variable
+ * only accessible within active context
+ * @...: context lock instance pointer(s)
*
* Declares that the struct member or global variable is only accessible within
- * the context entered by the given context lock. Read operations on the data
- * require shared access, while write operations require exclusive access.
+ * the context entered by the given context lock(s). Read operations on the data
+ * require shared access to at least one of the context locks, while write
+ * operations require exclusive access to all listed context locks.
*
* .. code-block:: c
*
@@ -52,17 +54,24 @@
* spinlock_t lock;
* long counter __guarded_by(&lock);
* };
+ *
+ * struct some_state {
+ * spinlock_t lock1, lock2;
+ * long counter __guarded_by(&lock1, &lock2);
+ * };
*/
# define __guarded_by(...) __attribute__((guarded_by(__VA_ARGS__)))
/**
- * __pt_guarded_by - struct member and globals attribute, declares pointed-to
- * data only accessible within active context
+ * __pt_guarded_by() - struct member and globals attribute, declares pointed-to
+ * data only accessible within active context
+ * @...: context lock instance pointer(s)
*
* Declares that the data pointed to by the struct member pointer or global
* pointer is only accessible within the context entered by the given context
- * lock. Read operations on the data require shared access, while write
- * operations require exclusive access.
+ * lock(s). Read operations on the data require shared access to at least one
+ * of the context locks, while write operations require exclusive access to all
+ * listed context locks.
*
* .. code-block:: c
*
@@ -70,6 +79,11 @@
* spinlock_t lock;
* long *counter __pt_guarded_by(&lock);
* };
+ *
+ * struct some_state {
+ * spinlock_t lock1, lock2;
+ * long *counter __pt_guarded_by(&lock1, &lock2);
+ * };
*/
# define __pt_guarded_by(...) __attribute__((pt_guarded_by(__VA_ARGS__)))
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 8ff5adc..b0f3028 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -630,7 +630,7 @@ config DEBUG_FORCE_WEAK_PER_CPU
config WARN_CONTEXT_ANALYSIS
bool "Compiler context-analysis warnings"
- depends on CC_IS_CLANG && CLANG_VERSION >= 220100
+ depends on CC_IS_CLANG && CLANG_VERSION >= 230000
# Branch profiling re-defines "if", which messes with the compiler's
# ability to analyze __cond_acquires(..), resulting in false positives.
depends on !TRACE_BRANCH_PROFILING
@@ -641,7 +641,7 @@ config WARN_CONTEXT_ANALYSIS
and releasing user-definable "context locks".
Clang's name of the feature is "Thread Safety Analysis". Requires
- Clang 22.1.0 or later.
+ Clang 23 or later.
Produces warnings by default. Select CONFIG_WERROR if you wish to
turn these warnings into errors.
diff --git a/lib/test_context-analysis.c b/lib/test_context-analysis.c
index 06b4a6a..316f4df 100644
--- a/lib/test_context-analysis.c
+++ b/lib/test_context-analysis.c
@@ -159,6 +159,10 @@ TEST_SPINLOCK_COMMON(read_lock,
struct test_mutex_data {
struct mutex mtx;
int counter __guarded_by(&mtx);
+
+ struct mutex mtx2;
+ int anyread __guarded_by(&mtx, &mtx2);
+ int *anyptr __pt_guarded_by(&mtx, &mtx2);
};
static void __used test_mutex_init(struct test_mutex_data *d)
@@ -219,6 +223,26 @@ static void __used test_mutex_cond_guard(struct test_mutex_data *d)
}
}
+static void __used test_mutex_multiguard(struct test_mutex_data *d)
+{
+ mutex_lock(&d->mtx);
+ (void)d->anyread;
+ (void)*d->anyptr;
+ mutex_unlock(&d->mtx);
+
+ mutex_lock(&d->mtx2);
+ (void)d->anyread;
+ (void)*d->anyptr;
+ mutex_unlock(&d->mtx2);
+
+ mutex_lock(&d->mtx);
+ mutex_lock(&d->mtx2);
+ d->anyread++;
+ (*d->anyptr)++;
+ mutex_unlock(&d->mtx2);
+ mutex_unlock(&d->mtx);
+}
+
struct test_seqlock_data {
seqlock_t sl;
int counter __guarded_by(&sl);
^ permalink raw reply related [flat|nested] 10+ messages in thread