Re: [PATCH v12 4/4] x86/cpu: Clear feature bits whose dependencies were cleared

[Maciej Wieczor-Retman]

On 2026-03-27 at 19:22:27 -0700, H. Peter Anvin wrote:
>On 2026-03-27 08:11, Maciej Wieczor-Retman wrote:
>> From: Maciej Wieczor-Retman <maciej.wieczor-retman@xxxxxxxxx>
>> 
>> After cpu_caps_cleared[] is initialized with DISABLED_MASK_INIT,
>> features present in disabled bitmasks are cleared from x86_capability[].
>> However features that depend on them and are not part of any disabled
>> mask are not cleared by anything. They can trigger the warning in
>> check_cpufeature_deps(), as before both features would show up as
>> enabled even though they weren't. The uncleared features can also still
>> falsely show up in /proc/cpuinfo.
>> 
>> Take such cases into account before applying the cpu_caps_cleared[]
>> array.
>> 
>> +/*
>> + * If the dependency was cleared through the disabled bitmasks while the
>> + * feature wasn't it also needs to be cleared.
>> + */
>> +void clear_feature_disabled_deps(struct cpuinfo_x86 *c)
>> +{
>> +	const struct cpuid_dep *d;
>> +
>> +	for (d = cpuid_deps; d->feature; d++) {
>> +		if (!DISABLED_MASK_BIT_SET(d->feature) && DISABLED_MASK_BIT_SET(d->depends))
>> +			set_bit(d->feature, (unsigned long *)cpu_caps_cleared);
>> +	}
>> +}
>> +
>
>Thinking about it, if this is discovered at runtime, it is really too late,
>because in a sense we have miscompiled the kernel with unwanted code (as we
>should have compiled out these features just as with other DISABLED features.)
>
>This ultimately reflects a failed dependency in Kconfig.cpufeatures, which may
>have caused kconfig to do the Wrong Thing[TM]. So at the very least it might
>be a good thing to print a message here saying Kconfig.cpufeatures should be
>fixed.

So how about a warning (for any future cases) and add a new patch to fix SGX (so
the current known problem is solved)?

>The better option, which I don't know how difficult it would be, would be to
>make the dependencies available to Kconfig. This sounds like something that
>would fall in the scope of Ahmed's rework rather than this patchset, though
>(Ahmed, would you agree?)
>
>	-hpa
>
>

-- 
Kind regards
Maciej Wieczór-Retman