mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Jim Mattson <jmattson@google.com>
Cc: Thomas Gleixner <tglx@kernel.org>,
	x86@kernel.org, linux-kernel@vger.kernel.org, yosry@kernel.org
Subject: Re: [PATCH 1/1] x86/CPU/AMD: Avoid racy updates to MSR_K7_HWCR in set_cpuid_faulting()
Date: Tue, 9 Jun 2026 16:27:46 -0700	[thread overview]
Message-ID: <20260609232746.GAaiihcp9EItlpkCB4@fat_crate.local> (raw)
In-Reply-To: <CALMp9eTD5ZYkAOd3POD9_LEeB9=aVxj08fSZKvHNq3dMmvPCCg@mail.gmail.com>

On Tue, Jun 09, 2026 at 03:08:22PM -0700, Jim Mattson wrote:
> Yes, I'd be happy to.

Thanks!

I haven't heard that in a while - it is usually grumbling :-P

> Most HWCR updates are in init code, so they should be fine. Should I
> call the helper from init code anyway?

Pfff, looking around the tree, we've accumulated a lot of HWCR pokers... I'm
thinking perhaps we should leave the obviously non-problematic ones alone for
now and convert only the problematic ones at first and then slowly, convert
the rest. Otherwise, that'll be a bunch of patch churn at once...

> If this can race with boost_set_msr_each(),

You mean if someone echoes into sysfs to toggle boost and yanks the module
at the same time? Pff, I fail to see the valid use case here but I won't be
surprised.

> then the bigger problem is that boost_set_msr_each() might set the
> boost-disable bit between the call to cpufreq_boost_down_prep() and the CPU
> going offline.

Offline? I think that's the module exit callback acpi_cpufreq_cpu_exit() which
calls it.

/me greps some more...

Uff, that's hit down the cpuhp_cpufreq_offline() path which is the hotplug
callback.

> I couldn't convince myself that cpufreq_boost_down_prep() was always
> called on the CPU going offline. The call to boost_set_msr() on the
> current CPU suggests it is, but the 'cpu' argument suggests it isn't.
> If policies are shared, my reading of __cpufreq_offline() is that
> cpufreq_driver->exit() [which calls cpufreq_boost_down_prep()] is only
> called when the last CPU sharing the policy goes offline, potentially
> leaving CPB_DIS set on the rest.

Yah, I see it the same. Unless we both are missing something, this looks
broken and prolly no one caught it because we're using amd-state now. And that
thing doesn't even touch CPB_DIS but does this pm_qos stuff in
amd_pstate_cpu_boost_update().

Dunno, do we care about a driver we don't use anymore... maybe, but low
prio...

> Anyway, since boost_set_msr() is called from both process context and
> interrupt context, perhaps I should use the helper in boost_set_msr()
> as well, just for consistency.

Yah, stick the call in the case ...HYGON/...AMD: branch and should be good.

I can test it then on some machines here.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

      reply	other threads:[~2026-06-09 23:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-09 21:15 [PATCH 0/1] Fix an HWCR RMW race Jim Mattson
2026-06-09 21:15 ` [PATCH 1/1] x86/CPU/AMD: Avoid racy updates to MSR_K7_HWCR in set_cpuid_faulting() Jim Mattson
2026-06-09 21:41   ` Borislav Petkov
2026-06-09 22:08     ` Jim Mattson
2026-06-09 23:27       ` Borislav Petkov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260609232746.GAaiihcp9EItlpkCB4@fat_crate.local \
    --to=bp@alien8.de \
    --cc=jmattson@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@kernel.org \
    --cc=x86@kernel.org \
    --cc=yosry@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®