Re: [tip: locking/core] compiler-context-analysis: Bump required Clang version to 23

[Niklas Cassel <cassel@kernel.org>]

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