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 <[email protected]> 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/[email protected]?part=9
