From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 3790B284682 for ; Wed, 17 Sep 2025 07:40:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758094839; cv=none; b=Qo8xIJ8DCezO1dwkf5JRdlexiGkPTGmE54lsavqpujNoNZo1+NtdRgUzH9QQT/1Ep2K80zsWV9csbZSu4aCgHEGlbPO0c0ibGBWvK5LDTSSgKSv5u5J1Zt+m1FkUxnmFnGLflQF5tCAESvptvz8QwFs1STMJ1iZgwt3Zet09keM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758094839; c=relaxed/simple; bh=qmIu/kSHPMaZ0Sb2VKPPv4ZxNstZQwTSRpHYbfclKdw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=FOgBgp3/xWBc1xTPYyh4GnSHTwk+lcuzKH6ad+RMjMfZArLGFC3MpQIQImG+pOY72KE9fwrlsclB6Hki86N7zTCCyzjQm+EEoa1NLGlqHRVu1kxKhrOdjPME5l70ZJ/mWL28gvbT7YrwoKjfIz6pCqiAiuV6eOlI81WN9Qag0ME= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=f4bvdTzQ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="f4bvdTzQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4C0DDC4CEF0; Wed, 17 Sep 2025 07:40:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1758094837; bh=qmIu/kSHPMaZ0Sb2VKPPv4ZxNstZQwTSRpHYbfclKdw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=f4bvdTzQVinwtj9+rD/nW+uYG2XdEZhCQV/nmcw0x5vJ32iNN5UJ7j9MFho2Ff1gJ KdyYDZvR+vVf9hqwlW7p2hWQliDV6Nn2JfTySjDRDd5GrRmxFCmT3k16kOkydXyU8c 0AZXj3uipigxhn6UwEgQKxFLqwYajq6PfzD/P4wc= Date: Wed, 17 Sep 2025 09:40:34 +0200 From: "gregkh@linuxfoundation.org" To: "Jitindar Singh, Suraj" Cc: "stable@vger.kernel.org" Subject: Re: [PATCH 5.10 0/4] x86/speculation: Make {JMP, CALL}_NOSPEC Consistent Message-ID: <2025091712-gizzard-patrol-e59d@gregkh> References: <20250903225003.50346-1-surajjs@amazon.com> <2025090450-plaster-shadiness-1283@gregkh> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Sep 16, 2025 at 08:41:33PM +0000, Jitindar Singh, Suraj wrote: > On Thu, 2025-09-04 at 14:00 +0200, Greg KH wrote: > > On Wed, Sep 03, 2025 at 03:49:59PM -0700, Suraj Jitindar Singh wrote: > > > The 4 patches in this series make the JMP_NOSPEC and CALL_NOSPEC > > > macros used > > > in the kernel consistent with what is generated by the compiler. > > > > > > ("x86,nospec: Simplify {JMP,CALL}_NOSPEC") was merged in v6.0 and > > > the remaining > > > 3 patches in this series were merged in v6.15. All 4 were included > > > in kernels > > > v5.15+ as prerequisites for the backport of the ITS mitigations > > > [1]. > > > > > > None of these patches were included in the backport of the ITS > > > mitigations to > > > the 5.10 kernel [2]. They all apply cleanly and are applicable to > > > the 5.10 > > > kernel. Thus I see no reason that they weren't applied here, unless > > > someone can > > > correct me? > > > > Do they actually fix anything? > > They do not, no. > > > > > > I am sending them for inclusion in the 5.10 kernel as this kernel > > > is still > > > actively maintained for these kind of vulnerability mitigations and > > > as such > > > having these patches will unify the handling of these cases with > > > subsequent > > > kernel versions easing code understanding and the ease of backports > > > in the > > > future. > > > > Does this actually allow this to happen?  I think there are a few > > speculation fixes that have not been backported to this kernel tree, > > so > > why not just make this as a part of that work instead?  Just adding > > infastructure that doesn't do anything isn't usually a good idea. > > > > In my case at least, it does. I had to spend time working out why this > code was different compared to newer stable and upstream, and > determining if this required special handling - which would not have > been necessary if this code was the same. Other speculation fixes don't > touch this path which is why it was included in the ITS mitigation > patch series for other stable versions. It does do something, any where > the macros are used this does something and is then rewritten by the > alternatives code. > > Trying to save my own (and anyone elses) sanity for having to work out > why this is different in the future in an area which does still get > regularly touched for these old kernels. Understand it doesn't fit the > regular stable patch mold but wanted to help in case these were just > unintentionally missed in this stable stream. But I acknowledge as you > point out that they are not fixing anything. If you want to include this as part of a patch series that does add additional speculation bugfixes, as it would make that series work easier, that's great, but on its own, it wouldn't make much sense to do this for no reason. good luck with keeping this alive, that's not an easy task. greg k-h