mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Sohil Mehta <sohil.mehta@intel.com>,
	"Ahmed S. Darwish" <darwi@linutronix.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
	Borislav Petkov <bp@alien8.de>,
	x86@kernel.org, Thomas Gleixner <tglx@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, "H . Peter Anvin" <hpa@zytor.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Richard Weinberger <richard@nod.at>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Tony Luck <tony.luck@intel.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()
Date: Mon, 18 May 2026 14:17:13 -0700	[thread overview]
Message-ID: <bfce05b0-5ca1-4690-bf4e-b19fd915907e@intel.com> (raw)
In-Reply-To: <fb581191-3d86-4907-9755-5afed1cfb977@intel.com>

On 5/18/26 13:29, Sohil Mehta wrote:
>> I think this pr_notice() is fine to remove.
> Sure, I'll remove the notice and also convert the #ifdef
> CONFIG_X86_F00F_BUG into IS_ENABLED(CONFIG_X86_F00F_BUG).

BTW... The basic trajectory these days is not to be so careful with
32-bit-only gunk. If it's causing us any headache -- even a few lines of
code -- it better be unambiguously crucial to functionality to stick around.

In this case, the guy still running a Pentium classic is highly unlikely
to be concerned about the kernel forgetting to add an F0 0F workaround.
There are also unlikely to be Pentiums sitting in data centers with log
monitoring tools that are desperately looking for that F0 0F hunk in dmesg.

The most likely thing is: there are a few dozen Pentiums (if that) out
there running mainline kernels. I'm not sure they even have more than a
couple of distros they can run. Nobody is going to notice this message
going away.

  reply	other threads:[~2026-05-18 21:18 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-15  0:24 [PATCH v2 0/3] x86: Fix a F00F bug warning and cleanup surrounding code Sohil Mehta
2026-05-15  0:24 ` [PATCH v2 1/3] x86/cpu/intel: Don't clear X86_BUG_F00F before setting it Sohil Mehta
2026-05-15 19:16   ` Ahmed S. Darwish
2026-05-15  0:24 ` [PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once() Sohil Mehta
2026-05-15 19:14   ` Ahmed S. Darwish
2026-05-15 22:37     ` Sohil Mehta
2026-05-15 23:09       ` Ahmed S. Darwish
2026-05-15 23:23     ` Dave Hansen
2026-05-18 20:29       ` Sohil Mehta
2026-05-18 21:17         ` Dave Hansen [this message]
2026-05-18 21:23           ` H. Peter Anvin
2026-05-21 22:38           ` Maciej W. Rozycki
2026-05-22  6:11             ` Christian Ludloff
2026-05-22 20:27               ` Maciej W. Rozycki
2026-05-25 10:41                 ` Maciej W. Rozycki
2026-05-26 20:56                   ` Richard Weinberger
2026-05-27  0:25                     ` Maciej W. Rozycki
2026-05-26 14:14                 ` Dave Hansen
2026-05-26 15:01                   ` Maciej W. Rozycki
2026-05-26 15:20                   ` David Laight
2026-05-26 17:43                     ` Christian Ludloff
2026-05-26 19:15                       ` Maciej W. Rozycki
2026-05-26 20:49                         ` H. Peter Anvin
2026-05-27  0:29                           ` Maciej W. Rozycki
2026-05-27  6:13                             ` H. Peter Anvin
2026-05-27  9:09                           ` David Laight
2026-05-27  9:23                             ` Maciej W. Rozycki
2026-05-27 15:36                               ` H. Peter Anvin
2026-05-27 16:14                                 ` Maciej W. Rozycki
2026-06-01 14:43                                   ` H. Peter Anvin
2026-06-01 21:45                                     ` David Laight
2026-05-15  0:25 ` [PATCH v2 3/3] x86/cpufeature: Remove clear_cpu_bug() Sohil Mehta
2026-05-15 19:16   ` Ahmed S. Darwish
2026-05-15  6:18 ` [PATCH v2 0/3] x86: Fix a F00F bug warning and cleanup surrounding code Richard Weinberger

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=bfce05b0-5ca1-4690-bf4e-b19fd915907e@intel.com \
    --to=dave.hansen@intel.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bp@alien8.de \
    --cc=darwi@linutronix.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jpoimboe@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=richard@nod.at \
    --cc=sohil.mehta@intel.com \
    --cc=tglx@kernel.org \
    --cc=tony.luck@intel.com \
    --cc=x86@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