[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2025073024-musky-smashing-812e@gregkh>
Date: Wed, 30 Jul 2025 07:55:10 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Suchit Karunakaran <suchitkarunakaran@...il.com>
Cc: tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
dave.hansen@...ux.intel.com, hpa@...or.com, darwi@...utronix.de,
sohil.mehta@...el.com, peterz@...radead.org, ravi.bangoria@....com,
skhan@...uxfoundation.org, linux-kernel-mentees@...ts.linux.dev,
linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH v3] x86/cpu/intel: Fix the constant_tsc model check for
Pentium 4s
On Wed, Jul 30, 2025 at 11:05:31AM +0530, Suchit Karunakaran wrote:
> On Wed, 30 Jul 2025 at 10:22, Greg KH <gregkh@...uxfoundation.org> wrote:
> >
> > On Wed, Jul 30, 2025 at 09:56:17AM +0530, Suchit Karunakaran wrote:
> > > The logic to synthesize constant_tsc for Pentium 4s (Family 15) is
> > > wrong. Since INTEL_P4_PRESCOTT is numerically greater than
> > > INTEL_P4_WILLAMETTE, the logic always results in false and never sets
> > > X86_FEATURE_CONSTANT_TSC for any Pentium 4 model.
> > > The error was introduced while replacing the x86_model check with a VFM
> > > one. The original check was as follows:
> > > if ((c->x86 == 0xf && c->x86_model >= 0x03) ||
> > > (c->x86 == 0x6 && c->x86_model >= 0x0e))
> > > set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC);
> >
> > What do you mean by "original check"? Before the change that caused
> > this, or what it should be?
> >
>
> Original check in this context refers to the change before the erroneous code.
>
> > > Fix the logic to cover all Pentium 4 models from Prescott (model 3) to
> > > Cedarmill (model 6) which is the last model released in Family 15.
> > >
> > > Fixes: fadb6f569b10 ("x86/cpu/intel: Limit the non-architectural constant_tsc model checks")
> > >
> > > Cc: <stable@...r.kernel.org> # v6.15
> > >
> > > Signed-off-by: Suchit Karunakaran <suchitkarunakaran@...il.com>
> >
> > Nit, no blank lines beween all of those last lines. Hint, look at all
> > of the patches on the mailing lists AND in the tree already, you have
> > hundreds of thousands of examples here of how to format things :)
> >
>
> Sorry about it. Should I send a new version of the patch removing the
> blank lines?
That's up to the maintainer(s) of this subsystem, if they want to
manually edit the change or not. As it's the middle of the merge
window, no one will probably be doing anything for another 2 weeks on it
anyway, so just relax and see what happens :)
thanks,
greg k-h
Powered by blists - more mailing lists