From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5648B3A6B9A; Thu, 28 May 2026 09:12:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779959568; cv=none; b=ESVOXxwBPWJ/R4IHsziJREJvh95Ioa+lfdUe71CmJZ/IMwvxaXCiRbjZgaQLI4LdTkXXEzJALXeWTKR3j4KvFSyLvZMYSYcSv5tZGM6LLvH8BTGQAXaRWmTiqa38D58ZxBgDP8rIGTS3rf8NSctwx2aOhDVh1fZ0//tLfodxLaw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779959568; c=relaxed/simple; bh=0SKc5bjFgVweIfHr8eWHL9aZzwMY/HiQ89gi0ndq788=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=WF31iTJdpobQbUIjr4ZA3S6a0Yv5zYJcXyggo45XQIQqEJd5hV7Uz9x2Ch8aNj8EmXmtzZyANX2k9Vcp05m3s2a9DVfuQDH9HmPu/gWuE9kgEYvVJSxM6SF7kwh6Fw08/luXhFdiGwoFZv8k7i7Qwu4nw2ptJ+MncJuRjqKRvHg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Lk4/AOCT; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Lk4/AOCT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 12B5A1F00A3A; Thu, 28 May 2026 09:12:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779959567; bh=DRtxMs8atNBiZONFPFKf7dNv82ZDbSfhRNgk1NiL8uc=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=Lk4/AOCTr2z9oKO4nbtiqCjd5FOywNgS0Eu7F08AU8KTmMSbSDJF/wRpHYmco3KFo pRYhmf5hfQ1fqUogaVsoPmMK2gCXEuNMVObVdeI2TzXgs81pyVVKjXdIecw8MbVVAc CsW+oguacLvRR1aSHDsQTZqppuUDw5cLtQHS4TIjf8RTRLorIN8t2JHvOjFKESIYQq ZVyk75c7dzIK3HjrxrGLcqUJXCmBkZwFq0IZBMv/A51k3AhBPKITn4rwFJgjqV7GCe FSOLQDOrBRcG6hWymJPnro+MBN+N476oC3I7DyxB5FWuz2RLyZy1stowPU+FQ0P7os wjelLnNq+p9zg== Date: Thu, 28 May 2026 11:12:42 +0200 From: Niklas Cassel To: linux-kernel@vger.kernel.org Cc: linux-tip-commits@vger.kernel.org, Marco Elver , "Peter Zijlstra (Intel)" , Nathan Chancellor , Bart Van Assche , x86@kernel.org, dlemoal@kernel.org Subject: Re: [tip: locking/core] compiler-context-analysis: Bump required Clang version to 23 Message-ID: References: <20260515124426.2227783-1-elver@google.com> <177926568868.711.3058599932884307249.tip-bot2@tip-bot2> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <177926568868.711.3058599932884307249.tip-bot2@tip-bot2> 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 > AuthorDate: Fri, 15 May 2026 14:43:31 +02:00 > Committer: Peter Zijlstra > 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 > Signed-off-by: Peter Zijlstra (Intel) > Reviewed-by: Nathan Chancellor > Reviewed-by: Bart Van Assche > 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