On 2025-07-24 at 13:12:33 +0300, Borislav Petkov wrote:
On July 24, 2025 12:45:51 PM GMT+03:00, Maciej Wieczor-Retman maciej.wieczor-retman@intel.com 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
Where?
Oh sorry, must've forgotten to save the changes after I renamed it. Anyway I just sent the corrected version as RESEND to this message.
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@intel.com Signed-off-by: Maciej Wieczor-Retman maciej.wieczor-retman@intel.com Cc: stable@vger.kernel.org
Changelog v3:
- Remove Fixes: tags, keep only one at the point where the documentation
changed and promised feature bits wouldn't show up if they're not enabled.
The behavior was there before. Why do you keep pointing at the patch which documents it?
Is my assumption incorrect, that before it was documented, the rules for feature flags were more loose and afterwards they were more strict? So before that documentation was written it could be classified under "undefined behavior".
As I wrote in the v2 thread, based on what's in the documentation added at the commit I pointed out, the behavior is a bug. Features that are disabled - due to not being compiled - are showing up in /proc/cpuinfo [1].
[1] https://github.com/torvalds/linux/blob/master/Documentation/arch/x86/cpuinfo...
-- Sent from a small device: formatting sucks and brevity is inevitable.