Re: [PATCH] x86/cpufeatures: Free up unused feature bits

[Sohil Mehta <sohil.mehta@intel.com>]

On 11/7/2024 5:12 PM, Dave Hansen wrote:
> Let's say
> we had an ooooooooold module that did this:
> 
> #ifdef MODULE
> static const struct x86_cpu_id foo_cpu_id[] = {
>         X86_MATCH_FEATURE(X86_FEATURE_P3, NULL),
>         {}
> };
> MODULE_DEVICE_TABLE(x86cpu, foo_cpu_id);
> #endif
> 
> which generated a modalias like this:
> 
> 	alias:          cpu:type:x86,ven*fam*mod*:feature:*0067*
> 
> and then we recycled number 67:
> 
> -#define X86_FEATURE_P3                  ( 3*32+ 6) /* P3 */
> +#define X86_FEATURE_WHIZZY_NEW_FEATURE  ( 3*32+ 6) /* P3 */
> 

Coretemp (hwmon) seems to follow this pattern exactly.

commit 9b38096fde5f ("HWMON: Convert coretemp to x86 cpuid autoprobing")
adds X86_FEATURE_DTS to MODULE_DEVICE_TABLE(x86cpu, coretemp_ids)

commit 2ccd71f1b278 ("x86/cpufeature: Move some of the scattered feature
bits to x86_capability") frees up X86_FEATURE_DTS(DTHERM).

-#define X86_FEATURE_DTHERM     ( 7*32+ 7) /* Digital Thermal Sensor */

commit 765a0542fdc7 ("x86/virt/tdx: Detect TDX during kernel boot")
reuses that bit.

+#define X86_FEATURE_TDX_HOST_PLATFORM  ( 7*32+ 7) /* Platform supports
being a TDX host */

> udev might try to load the old module on a new CPU with
> X86_FEATURE_WHIZZY_NEW_FEATURE that's not a P3.
> 

So an old coretemp module could get loaded when the above TDX bit is
set. Not sure how likely this scenario is or what can we do to avoid it now?

> I sure hope we haven't been using too many of these synthetic features
> in MODULE_DEVICE_TABLE()s, because we tend to move them around, but I
> guess it's possible.

At least features X86_FEATURE_P3 and X86_FEATURE_P4 seem safe to be
recycled as they haven't been used in MODULE_DEVICE_TABLE().