linux-kernel - Re: [STABLE REGRESSION] Possible missing backport of x86_match

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2024081217-putt-conform-4b53@gregkh>
Date: Mon, 12 Aug 2024 14:11:20 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Thorsten Leemhuis <regressions@...mhuis.info>
Cc: Thomas Lindroth <thomas.lindroth@...il.com>, stable@...r.kernel.org,
	tony.luck@...el.com, Dave Hansen <dave.hansen@...ux.intel.com>,
	"Borislav Petkov (AMD)" <bp@...en8.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Linux kernel regressions list <regressions@...ts.linux.dev>
Subject: Re: [STABLE REGRESSION] Possible missing backport of x86_match_cpu()
 change in v6.1.96

On Wed, Aug 07, 2024 at 10:15:23AM +0200, Thorsten Leemhuis wrote:
> [CCing the x86 folks, Greg, and the regressions list]
> 
> Hi, Thorsten here, the Linux kernel's regression tracker.
> 
> On 30.07.24 18:41, Thomas Lindroth wrote:
> > I upgraded from kernel 6.1.94 to 6.1.99 on one of my machines and
> > noticed that
> > the dmesg line "Incomplete global flushes, disabling PCID" had
> > disappeared from
> > the log.
> 
> Thomas, thx for the report. FWIW, mainline developers like the x86 folks
> or Tony are free to focus on mainline and leave stable/longterm series
> to other people -- some nevertheless help out regularly or occasionally.
> So with a bit of luck this mail will make one of them care enough to
> provide a 6.1 version of what you afaics called the "existing fix" in
> mainline (2eda374e883ad2 ("x86/mm: Switch to new Intel CPU model
> defines") [v6.10-rc1]) that seems to be missing in 6.1.y. But if not I
> suspect it might be up to you to prepare and submit a 6.1.y variant of
> that fix, as you seem to care and are able to test the patch.

Needs to go to 6.6.y first, right?  But even then, it does not apply to
6.1.y cleanly, so someone needs to send a backported (and tested) series
to us at stable@...r.kernel.org and we will be glad to queue them up
then.

thanks,

greg k-h