All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anton Protopopov <a.s.protopopov@gmail.com>
To: sashiko-reviews@lists.linux.dev
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH v2 bpf-next 15/18] resolve_btfids: Tag fmod_ret candidates as targets
Date: Tue, 10 Nov 2026 15:19:30 +0000	[thread overview]
Message-ID: <avM2ArYor7B6-g63@mail.gmail.com> (raw)
In-Reply-To: <sashiko-outbox-205381@kernel.org>

On 26/11/09 06:13PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue to consider:
> - [Low] resolve_btfids: skipped duplicate-named functions in
>   choose_functions()
> --
> 
> commit 51f98882bd7c33a728dede77756350958f73cb62
> Author: Anton Protopopov <a.s.protopopov@gmail.com>
> 
> resolve_btfids: Tag fmod_ret candidates as targets
> 
> This commit teaches resolve_btfids to parse .BTF_fmodret_candidates
> records emitted by the bpf_scan_ir plugin and tag eligible functions in
> BTF with bpf_fmodret and bpf_fmodret_retval:<values>.
> 
> > diff --git a/tools/bpf/resolve_btfids/fmodret.c b/tools/bpf/resolve_btfids/fmodret.c
> > new file mode 100644
> > index 0000000000000..df44b93eea734
> > --- /dev/null
> > +++ b/tools/bpf/resolve_btfids/fmodret.c
> 
> [ ... ]
> 
> > +/* Choose the targets among the functions and describe them in RESULT */
> > +static int choose_functions(struct elf_function_list *functions, const struct btf *btf,
> > +			    const struct btf_func *btf_funcs, size_t nr_btf_funcs,
> > +			    const unsigned char *buf, size_t ptr_size,
> > +			    unsigned int encoding, struct fmodret_retvals *result,
> > +			    struct fmodret_stats *stats, int verbose)
> > +{
> > +	size_t i = 0, j;
> > +
> > +	qsort(functions->functions, functions->nr, sizeof(*functions->functions),
> > +	      cmp_elf_function_name);
> > +	for (i = 0; i < functions->nr; i = j) {
> > +		const struct elf_function *f = &functions->functions[i];
> > +		size_t record = chosen_record(f);
> > +		const char *reason = NULL;
> > +		unsigned int flags = 0;
> > +		struct fmodret_retval *r;
> > +		__u32 size;
> > +		int id = 0;
> > +
> > +		for (j = i + 1; j < functions->nr; j++)
> > +			if (strcmp(f->name, functions->functions[j].name))
> > +				break;
> > +
> > +		if (!f->nr_strong && !f->nr_weak)
> > +			continue;
> > +		if (record == NO_FUNCTION) {
> > +			stats->ambiguous_body++;
> > +			reason = "ambiguous-body";
> > +			goto rejected;
> > +		}
> > +		/*
> > +		 * A strong definition without values has no record. If it
> > +		 * replaced a weak one, only the record of the weak one points
> > +		 * to its body.
> > +		 */
> > +		if (!f->nr_strong && !f->weak_symbol) {
> > +			stats->overridden++;
> > +			reason = "overridden-weak";
> > +			goto rejected;
> > +		}
> > +		if (!read_elf_value(buf + record + 16 + ptr_size, 4, encoding))
> > +			continue;
> > +		stats->with_values++;
> > +		flags = read_elf_value(buf + record + 12, 4, encoding);
> > +		if (j - i != 1) {
> > +			stats->ambiguous_name++;
> > +			reason = "ambiguous-name";
> > +			goto rejected;
> > +		}
> 
> [Severity: Low]
> Does advancing i = j while only inspecting functions->functions[i] skip
> candidate records on functions->functions[i + 1 .. j - 1] when multiple
> static functions share a name?
> 
> collect_elf_functions() gathers all defined STT_FUNC symbols regardless
> of whether they have an fmodret record.  If functions->functions[i] has no
> record (or zero values) while a later function with the same name in
> [i + 1, j) has a record with values, the continue statement jumps to j
> without counting the remaining functions in stats (such as
> stats->with_values and stats->ambiguous_name) or logging the
> ambiguous-name rejection when verbose > 1.

Yes, you're pointing to this the second time,
so it will be fixed in v3.

> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20261109170550.141443-1-a.s.protopopov@gmail.com?part=15

  reply	other threads:[~2026-11-10 15:08 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-09 17:05 [PATCH v2 bpf-next 00/18] Auto-detect BPF fmodret targets Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 01/18] bpf: Add BTF ID sets for fmod_ret targets Anton Protopopov
2026-11-09 17:42   ` bot+bpf-ci
2026-11-10 14:00     ` Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 02/18] bpf: Add a btf_id_set8_entry helper Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 03/18] bpf: Build fmod_ret target sets from BTF decl tags Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 04/18] selftests/bpf: Declare bpf_fentry_test1 in tracing tests Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 05/18] bpf: Declare fmod_ret targets with BTF_FMODRET sets Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 06/18] selftests/bpf: Test fmod_ret BTF decl tags and attach permission Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 07/18] scripts: Add LLVM plugin infrastructure Anton Protopopov
2026-11-09 17:45   ` sashiko-bot
2026-11-10 14:02     ` Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 08/18] bpf: Add the bpf_scan_ir LLVM plugin Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 09/18] bpf: Find fmod_ret candidates in bpf_scan_ir Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 10/18] bpf: Allow writes to private stack objects " Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 11/18] bpf: Follow PHIs " Anton Protopopov
2026-11-09 17:42   ` bot+bpf-ci
2026-11-10 14:04     ` Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 12/18] bpf: Follow integer casts " Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 13/18] bpf: Check the return values of fmod_ret programs on found targets Anton Protopopov
2026-11-09 17:42   ` bot+bpf-ci
2026-11-10 14:30     ` Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 14/18] bpf: Require the JIT for fmod_ret programs on found 64-bit targets Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 15/18] resolve_btfids: Tag fmod_ret candidates as targets Anton Protopopov
2026-11-09 17:42   ` bot+bpf-ci
2026-11-10 15:17     ` Anton Protopopov
2026-11-09 18:13   ` sashiko-bot
2026-11-10 15:19     ` Anton Protopopov [this message]
2026-11-09 17:05 ` [PATCH v2 bpf-next 16/18] selftests/bpf: Test fmod_ret candidates found by bpf_scan_ir Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 17/18] selftests/bpf: Enable bpf_scan_ir in the config Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 18/18] bpftool: List and show fmod_ret targets Anton Protopopov
2026-11-09 17:42   ` bot+bpf-ci
2026-11-10 15:30     ` Anton Protopopov

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=avM2ArYor7B6-g63@mail.gmail.com \
    --to=a.s.protopopov@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=sashiko-reviews@lists.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 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.