From: Eduard Zingerman <eddyz87@gmail.com>
To: bot+bpf-ci@kernel.org, bpf@vger.kernel.org, ast@kernel.org,
andrii@kernel.org
Cc: daniel@iogearbox.net, martin.lau@linux.dev, kernel-team@fb.com,
yonghong.song@linux.dev, martin.lau@kernel.org, clm@meta.com,
ihor.solodrai@linux.dev
Subject: Re: [PATCH bpf-next v2 02/13] bpf: save subprogram name in bpf_subprog_info
Date: Thu, 09 Apr 2026 21:04:38 -0700 [thread overview]
Message-ID: <57c439dabd29e7a1abd3f84b499cd407571781ab.camel@gmail.com> (raw)
In-Reply-To: <95b6b794090c7d1b35fa0040db3573cb6fdb0d9d566c313a14c942f029cbb56b@mail.kernel.org>
On Fri, 2026-04-10 at 01:50 +0000, bot+bpf-ci@kernel.org wrote:
> > diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
> > index 15f7f9f35be9..410939d7b325 100644
> > --- a/include/linux/bpf_verifier.h
> > +++ b/include/linux/bpf_verifier.h
> > @@ -664,6 +664,7 @@ enum priv_stack_mode {
> > };
> >
> > struct bpf_subprog_info {
> > + const char *name;
> > /* 'start' has to be the first field otherwise find_subprog() won't work */
> > u32 start; /* insn idx of function entry point */
>
> With name added before start, the comment claiming start has to be the
> first field is now inaccurate. Looking at find_subprog() and
> bpf_find_containing_subprog(), the binary search accesses the field by
> name (vals[m].start), not by raw offset, so field ordering doesn't
> actually matter:
>
> bpf_find_containing_subprog() {
> ...
> while (l < r) {
> m = l + (r - l + 1) / 2;
> if (vals[m].start <= off)
> l = m;
> else
> r = m - 1;
> }
> ...
> }
>
> Should the comment be updated or removed to avoid confusing future
> readers?
Comment does not seem to be accurate indeed.
I'll move the field and update the comment.
>
>
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
>
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/24221779050
next prev parent reply other threads:[~2026-04-10 4:04 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-10 1:11 [PATCH bpf-next v2 00/13] bpf: static stack liveness data flow analysis Eduard Zingerman
2026-04-10 1:11 ` [PATCH bpf-next v2 01/13] bpf: share several utility functions as internal API Eduard Zingerman
2026-04-10 1:11 ` [PATCH bpf-next v2 02/13] bpf: save subprogram name in bpf_subprog_info Eduard Zingerman
2026-04-10 1:50 ` bot+bpf-ci
2026-04-10 4:04 ` Eduard Zingerman [this message]
2026-04-10 1:11 ` [PATCH bpf-next v2 03/13] bpf: Add spis_*() helpers for 4-byte stack slot bitmasks Eduard Zingerman
2026-04-10 1:50 ` bot+bpf-ci
2026-04-10 4:05 ` Eduard Zingerman
2026-04-10 1:11 ` [PATCH bpf-next v2 04/13] bpf: make liveness.c track stack with 4-byte granularity Eduard Zingerman
2026-04-10 1:11 ` [PATCH bpf-next v2 05/13] bpf: 4-byte precise clean_verifier_state Eduard Zingerman
2026-04-10 1:11 ` [PATCH bpf-next v2 06/13] bpf: prepare bpf_liveness api for use by static analysis pass Eduard Zingerman
2026-04-10 1:11 ` [PATCH bpf-next v2 07/13] bpf: introduce forward arg-tracking dataflow analysis Eduard Zingerman
2026-04-10 2:02 ` bot+bpf-ci
2026-04-10 1:11 ` [PATCH bpf-next v2 08/13] bpf: simplify liveness to use (callsite, depth) keyed func_instances Eduard Zingerman
2026-04-10 2:02 ` bot+bpf-ci
2026-04-10 1:11 ` [PATCH bpf-next v2 09/13] bpf: change logging scheme for live stack analysis Eduard Zingerman
2026-04-10 2:02 ` bot+bpf-ci
2026-04-10 4:06 ` Eduard Zingerman
2026-04-10 1:11 ` [PATCH bpf-next v2 10/13] selftests/bpf: update existing tests due to liveness changes Eduard Zingerman
2026-04-10 1:11 ` [PATCH bpf-next v2 11/13] selftests/bpf: adjust verifier_log buffers Eduard Zingerman
2026-04-10 1:11 ` [PATCH bpf-next v2 12/13] selftests/bpf: add new tests for static stack liveness analysis Eduard Zingerman
2026-04-10 1:11 ` [PATCH bpf-next v2 13/13] bpf: poison dead stack slots Eduard Zingerman
2026-04-10 2:02 ` bot+bpf-ci
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=57c439dabd29e7a1abd3f84b499cd407571781ab.camel@gmail.com \
--to=eddyz87@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bot+bpf-ci@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=clm@meta.com \
--cc=daniel@iogearbox.net \
--cc=ihor.solodrai@linux.dev \
--cc=kernel-team@fb.com \
--cc=martin.lau@kernel.org \
--cc=martin.lau@linux.dev \
--cc=yonghong.song@linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox