[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <551e8238-84a1-4d5d-91c1-8d2adfde62e0@intel.com>
Date: Fri, 8 Nov 2024 10:42:24 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: "H. Peter Anvin" <hpa@...or.com>, Sohil Mehta <sohil.mehta@...el.com>,
x86@...nel.org, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
Sean Christopherson <seanjc@...gle.com>, Tony Luck <tony.luck@...el.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/cpufeatures: Free up unused feature bits
On 11/7/24 17:12, Dave Hansen wrote:
> and then we recycled number 67:
>
> -#define X86_FEATURE_P3 ( 3*32+ 6) /* P3 */
> +#define X86_FEATURE_WHIZZY_NEW_FEATURE ( 3*32+ 6) /* P3 */
>
> udev might try to load the old module on a new CPU with
> X86_FEATURE_WHIZZY_NEW_FEATURE that's not a P3.
Thinking about this a bit more...
The kernel generates _both_ the
"cpu:type:x86,ven*fam*mod*:feature:*0067*" string and the sysfs modalias
string. So the issue isn't practically a mismatch between those.
It's if some consumer of those fields (like /lib/udev/hwdb.d/) was
looking for feature 67.
The good news is that I don't see any of those today. But it's totally
possible that folks have some crazy rules out there. So we should
probably be _careful_ about changing those values and not just change
them *ALL*. But I think it's pretty unlikely we'll break anybody by
reusing a bit or two.
Powered by blists - more mailing lists