All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	"Kirill A. Shutemov" <kas@kernel.org>,
	Alexander Potapenko <glider@google.com>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Xin Li <xin3.li@intel.com>,
	Sai Praneeth <sai.praneeth.prakhya@intel.com>,
	Jethro Beekman <jethro@fortanix.com>,
	Jarkko Sakkinen <jarkko@kernel.org>,
	Sean Christopherson <seanjc@google.com>,
	Tony Luck <tony.luck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	"Mike Rapoport (IBM)" <rppt@kernel.org>,
	Kees Cook <kees@kernel.org>,
	Rick Edgecombe <rick.p.edgecombe@intel.com>,
	Yu-cheng Yu <yu-cheng.yu@intel.com>,
	stable@vger.kernel.org, Borislav Petkov <bp@suse.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] x86: Clear feature bits disabled at compile-time
Date: Wed, 23 Jul 2025 11:45:22 +0200	[thread overview]
Message-ID: <2025072310-eldest-paddle-99b3@gregkh> (raw)
In-Reply-To: <20250723092250.3411923-1-maciej.wieczor-retman@intel.com>

On Wed, Jul 23, 2025 at 11:22:49AM +0200, Maciej Wieczor-Retman wrote:
> If some config options are disabled during compile time, they still are
> enumerated in macros that use the x86_capability bitmask - cpu_has() or
> this_cpu_has().
> 
> The features are also visible in /proc/cpuinfo even though they are not
> enabled - which is contrary to what the documentation states about the
> file. Examples of such feature flags are lam, fred, sgx, ibrs_enhanced,
> split_lock_detect, user_shstk, avx_vnni and enqcmd.
> 
> Add a DISABLED_MASK() macro that returns 32 bit chunks of the disabled
> feature bits bitmask.
> 
> Initialize the cpu_caps_cleared and cpu_caps_set arrays with the
> contents of the disabled and required bitmasks respectively. Then let
> apply_forced_caps() clear/set these feature bits in the x86_capability.
> 
> Fixes: 6449dcb0cac7 ("x86: CPUID and CR3/CR4 flags for Linear Address Masking")
> Fixes: 51c158f7aacc ("x86/cpufeatures: Add the CPU feature bit for FRED")
> Fixes: 706d51681d63 ("x86/speculation: Support Enhanced IBRS on future CPUs")
> Fixes: e7b6385b01d8 ("x86/cpufeatures: Add Intel SGX hardware bits")
> Fixes: 6650cdd9a8cc ("x86/split_lock: Enable split lock detection by kernel")
> Fixes: 701fb66d576e ("x86/cpufeatures: Add CPU feature flags for shadow stacks")
> Fixes: ff4f82816dff ("x86/cpufeatures: Enumerate ENQCMD and ENQCMDS instructions")

That is fricken insane.

You are saying to people who backport stuff:
	This fixes a commit found in the following kernel releases:
		6.4
		6.9
		3.16.68 4.4.180 4.9.137 4.14.81 4.18.19 4.19
		5.11
		5.7
		6.6
		5.10

You didn't even sort this in any sane order, how was it generated?

What in the world is anyone supposed to do with this?

If you were sent a patch with this in it, what would you think?  What
could you do with it?

Please be reasonable and consider us overworked stable maintainers and
give us a chance to get things right.  As it is, this just makes things
worse...

greg k-h

  reply	other threads:[~2025-07-23  9:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-23  9:22 [PATCH v2] x86: Clear feature bits disabled at compile-time Maciej Wieczor-Retman
2025-07-23  9:45 ` Greg KH [this message]
2025-07-23 11:46   ` Maciej Wieczor-Retman
2025-07-23 11:57     ` Greg KH
2025-07-23 13:03       ` Maciej Wieczor-Retman
2025-07-23 13:37         ` Greg KH
2025-07-23 15:52         ` Xin Li
2025-07-24  0:24           ` Xin Li
2025-07-23 13:46 ` Borislav Petkov
2025-07-23 15:13   ` Maciej Wieczor-Retman
2025-07-23 15:28     ` H. Peter Anvin
2025-07-23 17:13       ` Maciej Wieczor-Retman
2025-07-23 17:23         ` H. Peter Anvin
2025-07-23 14:08 ` H. Peter Anvin
2025-07-23 16:17   ` Maciej Wieczor-Retman

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=2025072310-eldest-paddle-99b3@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=bp@alien8.de \
    --cc=bp@suse.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=glider@google.com \
    --cc=hpa@zytor.com \
    --cc=jarkko@kernel.org \
    --cc=jethro@fortanix.com \
    --cc=kas@kernel.org \
    --cc=kees@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maciej.wieczor-retman@intel.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rick.p.edgecombe@intel.com \
    --cc=rppt@kernel.org \
    --cc=sai.praneeth.prakhya@intel.com \
    --cc=seanjc@google.com \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    --cc=xin3.li@intel.com \
    --cc=yu-cheng.yu@intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.