Re: [PATCH 1/3] kconfig: Add "def_string", "def_int" and "def_hex"

[Julian Braha <julianbraha@gmail.com>]

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/20260727001623.2794156-1-julianbraha@gmail.com/

- Julian Braha