From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 26AFD28D8DB; Thu, 28 May 2026 09:37:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779961049; cv=none; b=MKi7qnEk9Bua7mBMjIXZpGDMx9D/hBpxDLleXFxE+stlimzLwujk/XPwhonHfsrZTEoZC5bH3E+S67wG9u8Yg6YPEyXWjUFv29hB4imo1xkobMZHNy2lZBmg/AGWlrBXsS9D1O91Tp0HVNJowkYQPyIZda6oOrBG5RgDn1pkrYc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779961049; c=relaxed/simple; bh=WWCTe02iQ4U7s0i+AdQyZ4in08sN78F0Y+nWIc3hwUo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=saHvI7J8VNWui0g9LQKKLQtBZQjZVUQ+WxtP5VH7i3Z4UGgnudzleCVAfURScvWMAw8Sfss/qHWdUOi3hFluwaQr1c4uBUN2A+C2E52YoV+r/TqmugKixJnrrVeYCSsVp9gnkWhTTbYjcjmwWWTrre/tfhb8oRGM5+f8Ss4wVXo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=psfTHAC+; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="psfTHAC+" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=/rVuCZrKNE5zKkvkp0JAOxhLeyhDuitFkiWGNZk0BwU=; b=psfTHAC+v4PNq/QTW9SeFNe2BH b1+1/mV/jXB71EvPLQwCuhA2Qs/g1tu+T2/AUKqx6+pxW7N7Noim8JwjqhmWYHvMxenyl8mEPOYEo 6lFNkY+S0GhhjNITvlFlKD146Wo+/0nHa9JP4kIVg47ndu5X8O5bCy+VsW/Tq/JChJC45NQfrqjYd nwItWnbKv1oVurhRo9dGWie14dF4wzeyZmbeN4+xMVzxTQvmiQ0SwROK2Pwd4GUi8pSVPfu+/ipve GENMzkEQ2fXn6R2lFA+O1QcXrsehVTDP5uycxaWcRoR3ZQ0mg9q0b8eDaX8jb5fS4HpK5pRm9BFpU YjMdeMlg==; Received: from 2001-1c00-8d85-4b00-266e-96ff-fe07-7dcc.cable.dynamic.v6.ziggo.nl ([2001:1c00:8d85:4b00:266e:96ff:fe07:7dcc] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wSXB5-0000000440u-2uej; Thu, 28 May 2026 09:37:24 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 346EC300673; Thu, 28 May 2026 11:37:22 +0200 (CEST) Date: Thu, 28 May 2026 11:37:22 +0200 From: Peter Zijlstra To: Niklas Cassel Cc: linux-kernel@vger.kernel.org, linux-tip-commits@vger.kernel.org, Marco Elver , 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: <20260528093722.GD343181@noisy.programming.kicks-ass.net> 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: 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 > > 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.) 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 :-)