[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <sjyqxudrd7scajhdq3u6kj2r5z2de4e6taju7e5fnas4lb7tad@uava65acipk2>
Date: Thu, 24 Jul 2025 14:43:49 +0200
From: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>
To: Greg KH <greg@...ah.com>
CC: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
<x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>, Ricardo Neri
<ricardo.neri-calderon@...ux.intel.com>, Tony Luck <tony.luck@...el.com>,
Kyung Min Park <kyung.min.park@...el.com>, <xin3.li@...el.com>, Farrah Chen
<farrah.chen@...el.com>, <stable@...r.kernel.org>, Borislav Petkov
<bp@...e.de>, <linux-kernel@...r.kernel.org>
Subject: Re: [RESEND PATCH v3] x86: Clear feature bits disabled at
compile-time
On 2025-07-24 at 14:41:27 +0200, Maciej Wieczor-Retman wrote:
>On 2025-07-24 at 13:34:44 +0200, Greg KH wrote:
>>Your reply-to is messed up :(
>>
>>On Thu, Jul 24, 2025 at 12:45:35PM +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_INITIALIZER macro that creates an initializer list
>>> filled with DISABLED_MASKx bitmasks.
>>>
>>> Initialize the cpu_caps_cleared array with the autogenerated disabled
>>> bitmask.
>>>
>>> Fixes: ea4e3bef4c94 ("Documentation/x86: Add documentation for /proc/cpuinfo feature flags")
>>> Reported-by: Farrah Chen <farrah.chen@...el.com>
>>> Signed-off-by: H. Peter Anvin (Intel) <hpa@...or.com>
>>> Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>
>>> Cc: <stable@...r.kernel.org>
>>> ---
>>> Resend:
>>> - Fix macro name to match with the patch message.
>>
>>That's a v4, not a RESEND.
>>
>>Doesn't Intel have a "Here is how to submit a patch to the kernel"
>>training program you have to go through?
>>
>>confused,
>>
>>greg k-h
>
>The way I did it used to work for me previously, I'm not sure why it didn't this
>time.
I meant the reply-to being messed up used to work, this indeed should have been
v4, I'll submit it properly.
--
Kind regards
Maciej Wieczór-Retman
Powered by blists - more mailing lists