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 3847D3BCD31; Thu, 28 May 2026 10:44:07 +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=1779965054; cv=none; b=X1d96av6Ood9f7MUcp9xouqX2MbpTljHpsoG5az/5Y+f9APH633q16BfD9Y4TM3t34gzOZHjImGXkuqNsVzeF6y/hpaTdL+QgFc6p+ZwRuVkDrr7fcgS7H/mNsat+P4gUaDWBlIXrfvz7RqYNr6e/NyCuViQ0lUovR7KzgZojPE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779965054; c=relaxed/simple; bh=VU2Z6MP7j4bnznVoUVh5Kpyn7iYMMnrfH/Uik72p5Kk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ryDf7OGpmBr1Owd4cYyeW1GHlVV69mOct0QnIA4biTNUChJ7xG9dyZKPGZ4b1nUuSf9p03v3SC13+ilgtjxPE1pheeqlIOAxkUYwRQ9k8eizAhKpawD0tlU+RCP6Y0Kcp02t347yjEyzXrlqmV1bVDniHPixHiwEz0gQ4Q5zMVU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VhtVxvXV; 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="VhtVxvXV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8A1431F000E9; Thu, 28 May 2026 10:44:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779965046; bh=g/1ZJqxogtkAXFL0C/bncZn6gKxNJsAu1utSQ5OghEw=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=VhtVxvXVMnZ00nIbKJuHRdXap3PAN/z7lGN/6aECryONpjX6UDDeNGcZcIYsQ9Wm9 JRslXG3J73QawYCd7FO/hIYR5+x/Q2WxmqdGBMBijnipyzFedOv/Pe3YvkjjhnKYE+ EsYA/EsYZ9W8PY7G4lANARB5pr+dvDNFKKmyBT2HlIGBorHtvih+sgvpsgSnogGJM4 wmN1H+Vg2hE4q3tR7k7AK47g0EoWzpt+lEXQEuF2ggppjxSAeRJLb4RaLSOWaBIO4p 72ycPsNVBDaVR9/sDK+0euvWSXXUYPv6d8cD7CO6pyKyMBa/YJpcC+VAWDUoM1tyrE pfE8DDSXe0u3g== Date: Thu, 28 May 2026 12:44:02 +0200 From: Niklas Cassel To: Peter Zijlstra 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: References: <20260515124426.2227783-1-elver@google.com> <177926568868.711.3058599932884307249.tip-bot2@tip-bot2> <20260528093722.GD343181@noisy.programming.kicks-ass.net> <20260528102703.GE343181@noisy.programming.kicks-ass.net> 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: <20260528102703.GE343181@noisy.programming.kicks-ass.net> 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