Re: [PATCH bpf-next v4 09/12] bpf, trace, net: prepare CONFIG_DEBUG_INFO_BTF checks for a tristate

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] kconfig: bool options depending on DEBUG_INFO_BTF are disabled when =m
--

commit cc56fafe832c4d8fb30d0a4f3b0686d5906ac2ec
Author: Jay Wang [off-list ref]

bpf, trace, net: prepare CONFIG_DEBUG_INFO_BTF checks for a tristate

This commit prepares the tree for CONFIG_DEBUG_INFO_BTF becoming a tristate
by updating preprocessor conditionals and Kconfig dependencies so that BTF
generation works correctly for both built-in (=y) and module (=m)
configurations.

bpf, trace, net: prepare CONFIG_DEBUG_INFO_BTF checks for a tristate

The next patch makes CONFIG_DEBUG_INFO_BTF a tristate.  With =m, Kconfig

[Severity: Medium]
When CONFIG_DEBUG_INFO_BTF becomes a tristate, will this cause bool options
that depend on it to evaluate to 'n' when it is set to 'm'?

For example, looking at DEBUG_INFO_BTF_MODULES in lib/Kconfig.debug:

config DEBUG_INFO_BTF_MODULES
	bool "Generate BTF type information for kernel modules"
	default y
	depends on DEBUG_INFO_BTF && MODULES

If a bool option's dependency evaluates to 'm', the highest value it can
take is 'm'. Since it is a boolean and cannot be 'm', it is forced to
evaluate to 'n' and is completely disabled.

Does configuring CONFIG_DEBUG_INFO_BTF=m unintentionally and silently disable
module BTF generation and all associated BTF-dependent features (such as
SCHED_CLASS_EXT and BINFMT_MISC_BPF)?

This would seem to contradict the goal of keeping module BTF active when
CONFIG_DEBUG_INFO_BTF is set to 'm'.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261001225214.12351-1-wanjay@amazon.com?part=9