[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251101100325.GAaQXa7UF-Ru2yqdI1@fat_crate.local>
Date: Sat, 1 Nov 2025 11:03:25 +0100
From: Borislav Petkov <bp@...en8.de>
To: Marc Herbert <marc.herbert@...ux.intel.com>
Cc: "H. Peter Anvin" <hpa@...or.com>, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/msr: add CPU_OUT_OF_SPEC taint name to
"unrecognized" pr_warn(msg)
On Sat, Nov 01, 2025 at 03:10:24AM +0000, Marc Herbert wrote:
> While restricting access, commit a7e1f67ed29f ("x86/msr: Filter MSR
> writes") also added warning and tainting. But the warning message never
> mentioned tainting. Moreover, this uses the "CPU_OUT_OF_SPEC" flag which
> is not clearly related to MSRs: that flag is overloaded by several,
> fairly different situations, including some much scarier ones. So,
Taint flags are expensive and we don't have flag for everything. And when
userspace is poking at MSRs, that's similar to putting the CPU in
a out-of-specification mode of sorts. So I took what's closest.
> without an expert around (thank you Dave Hansen), it would have been
> practically impossible to root cause the tainting from just the log file
> at hand. Fix this by simply appending the CPU_OUT_OF_SPEC flag to the
> warning message.
>
> This readability issue happened when staring at logs involving the
> Intel Memory Latency Checker (among many other things going on in that
> log). The MLC disables hardware prefetch.
Thanks for the background.
What is not clear to me is why do you need to dump the fact that it tainted
here and dump the taint flag too?
Also, why aren't you using print_tainted() if that is really necessary?
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists