All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Jay Wang" <wanjay@amazon.com>
Cc: "Petr Pavlu" <petr.pavlu@suse.com>,
	linux-input@vger.kernel.org, linux-modules@vger.kernel.org,
	gary@garyguo.net, linux-perf-users@vger.kernel.org,
	sched-ext@lists.linux.dev, linux-trace-kernel@vger.kernel.org,
	ojeda@kernel.org, dmitry.torokhov@gmail.com, bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v4 09/12] bpf, trace, net: prepare CONFIG_DEBUG_INFO_BTF checks for a tristate
Date: Fri, 02 Oct 2026 09:14:13 +0000	[thread overview]
Message-ID: <20261002091413.9B3981F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20261001225214.12351-10-wanjay@amazon.com>

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 <wanjay@amazon.com>

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

  reply	other threads:[~2026-10-02  9:14 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-01 22:52 [PATCH bpf-next v4 00/12] bpf: make the vmlinux BTF an on-demand loadable module (CONFIG_DEBUG_INFO_BTF=m) to save ~5.4 MB memory Jay Wang
2026-10-01 22:52 ` [PATCH bpf-next v4 01/12] bpf: pass the vmlinux BTF to btf_parse_module() and let it adopt the data Jay Wang
2026-10-02  9:14   ` sashiko-bot
2026-10-01 22:52 ` [PATCH bpf-next v4 02/12] bpf: split the kfunc, dtor kfunc and struct_ops registration bodies Jay Wang
2026-10-02  9:14   ` sashiko-bot
2026-10-01 22:52 ` [PATCH bpf-next v4 03/12] bpf: fetch the vmlinux BTF where kernel types enter a program Jay Wang
2026-10-02  9:14   ` sashiko-bot
2026-10-01 22:52 ` [PATCH bpf-next v4 04/12] bpf: take the vmlinux BTF from the btf_vmlinux module Jay Wang
2026-10-01 23:45   ` bot+bpf-ci
2026-10-02  9:14   ` sashiko-bot
2026-10-02 11:48   ` Alexei Starovoitov
2026-10-01 22:52 ` [PATCH bpf-next v4 05/12] bpf, tracing: load the vmlinux BTF where tracefs and bpffs requests start Jay Wang
2026-10-02  9:14   ` sashiko-bot
2026-10-01 22:52 ` [PATCH bpf-next v4 06/12] bpf: defer vmlinux kfunc and struct_ops registrations Jay Wang
2026-10-02  9:14   ` sashiko-bot
2026-10-01 22:52 ` [PATCH bpf-next v4 07/12] bpf: keep module BTF until the vmlinux BTF is available Jay Wang
2026-10-01 23:45   ` bot+bpf-ci
2026-10-02  9:14   ` sashiko-bot
2026-10-01 22:52 ` [PATCH bpf-next v4 08/12] bpf: expose deferred .BTF.base module BTF in sysfs from module load Jay Wang
2026-10-02  9:14   ` sashiko-bot
2026-10-01 22:52 ` [PATCH bpf-next v4 09/12] bpf, trace, net: prepare CONFIG_DEBUG_INFO_BTF checks for a tristate Jay Wang
2026-10-02  9:14   ` sashiko-bot [this message]
2026-10-05 11:32   ` Nicolas Schier
2026-10-01 22:52 ` [PATCH bpf-next v4 10/12] resolve_btfids: add --btf_link to fill in .BTF.link records Jay Wang
2026-10-01 23:29   ` bot+bpf-ci
2026-10-02  9:14   ` sashiko-bot
2026-10-01 22:52 ` [PATCH bpf-next v4 11/12] tools, samples: take the vmlinux BTF from vmlinux.unstripped first Jay Wang
2026-10-02  9:14   ` sashiko-bot
2026-10-05 11:17   ` Nicolas Schier
2026-10-01 22:52 ` [PATCH bpf-next v4 12/12] kbuild, bpf: allow building the vmlinux BTF as a module Jay Wang
2026-10-02  9:14   ` sashiko-bot
2026-10-02  9:47   ` Alan Maguire
2026-10-02  4:36 ` [PATCH bpf-next v4 00/12] bpf: make the vmlinux BTF an on-demand loadable module (CONFIG_DEBUG_INFO_BTF=m) to save ~5.4 MB memory Ihor Solodrai
2026-10-02  7:34   ` Jay Wang
2026-10-02 10:05     ` Alan Maguire
2026-10-02 20:58     ` Ihor Solodrai
2026-10-03  6:38       ` Alexei Starovoitov
2026-10-03 11:45         ` Alan Maguire
2026-10-03 12:19           ` Alexei Starovoitov
2026-10-04 22:21       ` Jay Wang
2026-10-05 19:01         ` Ihor Solodrai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261002091413.9B3981F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=gary@garyguo.net \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=ojeda@kernel.org \
    --cc=petr.pavlu@suse.com \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=sched-ext@lists.linux.dev \
    --cc=wanjay@amazon.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.