On 9/20/26 04:40, Kees Cook wrote:
>> The second problem, is that since the order of defaults matters and
>> conditions can shadow each other, def_<type> makes it harder for users
>> to get defaults right. In the past, I've seen several config options
>> with bugged defaults due to 'default' + 'def_<type>' [2][3][4].
>
> This is the one I, too, got worried about. From your example:
>
> config GUEST_STATE_BUFFER_TEST
> - def_tristate n
> + def_tristate KUNIT_ALL_TESTS
> prompt "Enable Guest State Buffer unit tests"
> depends on KUNIT
> depends on KVM_BOOK3S_HV_POSSIBLE
> - default KUNIT_ALL_TESTS
> help
>
> Is there a way to detect this state? (I assume as a follow-up; it's a
> general problem.)
Unfortunately there's no way to avoid some false alarms when checking
these due to macros.
Example:
config TUNE_CPU
string
depends on POWERPC64_CPU
default "-mtune=power10" if $(cc-option,-mtune=power10)
default "-mtune=power9" if $(cc-option,-mtune=power9)
default "-mtune=power8" if $(cc-option,-mtune=power8)
These macros get evaluated during preprocessing, which is ahead of when
the parse tree is finished and analysis can run.
Though a check for it is included in kconfirm (if merged) [1], and I've
also been thinking about making this part of an optional KCONFIG_LINT
setting, where some false positives could be acceptable.
[1]
https://lore.kernel.org/all/[email protected]/
- Julian Braha
