linux-kernel - Re: [PATCH v3] x86/cpu: Add INTEL_LUNARLAKE_M to X86_BUG

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: <CAJZ5v0iCR5ZbNz=OF1MbJUJdhCRh2P8M_MTF7eszPe5uv9_R1w@mail.gmail.com>
Date: Wed, 20 Nov 2024 21:08:18 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Dave Hansen <dave.hansen@...el.com>
Cc: Len Brown <lenb@...nel.org>, peterz@...radead.org, tglx@...utronix.de, 
	x86@...nel.org, rafael@...nel.org, linux-kernel@...r.kernel.org, 
	linux-pm@...r.kernel.org, Len Brown <len.brown@...el.com>, stable@...r.kernel.org
Subject: Re: [PATCH v3] x86/cpu: Add INTEL_LUNARLAKE_M to X86_BUG_MONITOR

On Wed, Nov 20, 2024 at 8:12 PM Dave Hansen <dave.hansen@...el.com> wrote:
>
> On 11/12/24 18:07, Len Brown wrote:
> > From: Len Brown <len.brown@...el.com>
> >
> > Under some conditions, MONITOR wakeups on Lunar Lake processors
> > can be lost, resulting in significant user-visible delays.
> >
> > Add LunarLake to X86_BUG_MONITOR so that wake_up_idle_cpu()
> > always sends an IPI, avoiding this potential delay.
>
> This kinda implies that X86_BUG_MONITOR only does one thing.  What about
> the two other places in the tree that check it.  Are those relevant?

They are relevant, but related.

The first one prevents mwait_idle() from becoming the default idle
function, which only matters if cpuidle is not used, but this is
consistent with the mwait_idle_with_hints() behavior.

The second one prevents KVM from using MWAIT in the guest which I
would think is a good idea in this case.

> > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219364
> >
> > Cc: stable@...r.kernel.org # 6.11
> > Signed-off-by: Len Brown <len.brown@...el.com>
>
> This obviously conflicts with the VFM infrastructure, but shouldn't this
> also get backported to even older stable kernels?

As a matter of principle, it should go to all of the stable kernel
series still in use, but it obviously needs backporting and I'm not
really sure how attractive the old kernel series will be for LNL users
(quite likely not at all).

> I thought the "# 6.11" was to tell folks where it is *needed*, not where
> it actually applies.

My interpretation is slightly different: This is the oldest series one
wants the given patch to go to.