All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anton Protopopov <a.s.protopopov@gmail.com>
To: bot+bpf-ci@kernel.org
Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
	eddyz87@gmail.com, memxor@gmail.com, almagui@kernel.org,
	john.fastabend@gmail.com, qmo@kernel.org, brauner@kernel.org,
	kpsingh@kernel.org, yonghong.song@linux.dev, jolsa@kernel.org,
	emil@etsalapatis.com, ihor.solodrai@linux.dev, sashal@kernel.org,
	bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
	martin.lau@kernel.org, mason@kernel.org
Subject: Re: [PATCH v1 bpf-next 15/18] resolve_btfids: Tag fmod_ret candidates as targets
Date: Mon, 9 Nov 2026 13:33:12 +0000	[thread overview]
Message-ID: <avHLmNLouxZX5z-e@mail.gmail.com> (raw)
In-Reply-To: <82dc259cd905abb5ad4fcbb8151553fb8680d4d71b1e52babd3e2d588a90656b@mail.kernel.org>

On 26/11/06 09:50PM, bot+bpf-ci@kernel.org wrote:
> > resolve_btfids: Tag fmod_ret candidates as targets
> 
> TL;DR: Nits only in resolve_btfids fmodret.c: duplicated alias-walk code in
> mark_traceable_function(), its unused bool return, and possibly obsolete
> section names (.meminit, .cpuinit, .devinit) in section_cannot_be_attached().
> 
> > diff --git a/tools/bpf/resolve_btfids/fmodret.c b/tools/bpf/resolve_btfids/fmodret.c
> > new file mode 100644
> > --- /dev/null
> > +++ b/tools/bpf/resolve_btfids/fmodret.c
> 
> [ ... ]
> 
> > +static bool mark_traceable_function(struct elf_function_list *list,
> > +				    Elf64_Section shndx, GElf_Addr address,
> > +				    enum ftrace_site_kind kind)
> > +{
> > +	size_t left = 0;
> > +	size_t right = list->nr;
> > +	size_t first;
> > +	size_t i;
> > +	bool found = false;
> 
> [ ... ]
> 
> > +	if (first != SIZE_MAX) {
> > +		while (first && list->functions[first - 1].shndx == shndx &&
> > +		       list->functions[first - 1].value ==
> > +						list->functions[first].value)
> > +			first--;
> > +		for (i = first; i < list->nr &&
> > +		     list->functions[i].shndx == shndx &&
> > +		     list->functions[i].value ==
> > +					list->functions[first].value; i++) {
> > +			list->functions[i].traceable = true;
> > +			found = true;
> > +		}
> > +		return found;
> > +	}
> > +	if (kind == FTRACE_SITE_PATCHABLE || !left)
> > +		return false;
> > +
> > +	/* The nearest preceding function owns the call site. */
> > +	first = left - 1;
> > +	if (list->functions[first].shndx != shndx)
> > +		return false;
> > +	while (first && list->functions[first - 1].shndx == shndx &&
> > +	       list->functions[first - 1].value == list->functions[first].value)
> > +		first--;
> > +	for (i = first; i < list->nr &&
> > +	     list->functions[i].shndx == shndx &&
> > +	     list->functions[i].value == list->functions[first].value; i++) {
> > +		if (!function_contains(&list->functions[i], address))
> > +			continue;
> > +		list->functions[i].traceable = true;
> > +		found = true;
> > +	}
> > +	return found;
> > +}
> 
> This isn't a bug, but mark_traceable_function() has two near-identical blocks
> that walk back to the first alias at a (shndx, value) pair and then loop
> forward over the aliases.  The second differs only by the
> function_contains() test.
> 
> Could the walk back use function_at(list, shndx, list->functions[first].value),
> with one forward loop that takes the containment test as a condition?  Then
> the two copies would not need to be kept in sync.
> 
> Also, this isn't a bug, but is the bool return of mark_traceable_function()
> meant for something, such as a -v count of unmatched ftrace sites?  None of
> its callers in mark_relocated_ftrace_sites() and read_ftrace_site_range()
> read the value, so could it return void and drop 'found'?

Both makes sense, will fix.

> [ ... ]
> 
> > +static bool section_cannot_be_attached(const char *name)
> > +{
> > +	return section_prefix(name, ".init.text") ||
> > +	       section_prefix(name, ".exit.text") ||
> > +	       section_prefix(name, ".noinstr.text") ||
> > +	       section_prefix(name, ".meminit.text") ||
> > +	       section_prefix(name, ".memexit.text") ||
> > +	       section_prefix(name, ".cpuinit.text") ||
> > +	       section_prefix(name, ".cpuexit.text") ||
> > +	       section_prefix(name, ".devinit.text") ||
> > +	       section_prefix(name, ".devexit.text");
> > +}
> 
> This isn't a bug, but are .meminit.text, .memexit.text, .cpuinit.text,
> .cpuexit.text, .devinit.text and .devexit.text still emitted anywhere?
> 
> In include/linux/init.h, __meminit is now either empty or __init, and the
> __cpuinit/__devinit annotations were removed.  Neither vmlinux.lds.h nor
> scripts/module.lds.S places these sections, and modpost lists only
> .init.text and .exit.text as init/exit text.
> 
> If they are gone, could section_cannot_be_attached() be reduced to
> .init.text, .exit.text and .noinstr.text?
> 

Makes sense, will fix. Thanks robot.

> ---
> 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/42294987431


  reply	other threads:[~2026-11-09 13:21 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-06 21:02 [PATCH v1 bpf-next 01/18] bpf: Add BTF ID sets for fmod_ret targets Anton Protopopov
2026-11-06 21:02 ` [PATCH v1 bpf-next 02/18] bpf: Add a btf_id_set8_entry helper Anton Protopopov
2026-11-06 20:58   ` sashiko-bot
2026-11-09 13:02     ` Anton Protopopov
2026-11-06 21:02 ` [PATCH v1 bpf-next 03/18] bpf: Build fmod_ret target sets from BTF decl tags Anton Protopopov
2026-11-06 21:02 ` [PATCH v1 bpf-next 04/18] selftests/bpf: Declare bpf_fentry_test1 in tracing tests Anton Protopopov
2026-11-06 21:02 ` [PATCH v1 bpf-next 05/18] bpf: Declare fmod_ret targets with BTF_FMODRET sets Anton Protopopov
2026-11-06 21:02 ` [PATCH v1 bpf-next 06/18] selftests/bpf: Test fmod_ret BTF decl tags and attach permission Anton Protopopov
2026-11-06 21:02 ` [PATCH v1 bpf-next 07/18] scripts: Add LLVM plugin infrastructure Anton Protopopov
2026-11-06 21:02 ` [PATCH v1 bpf-next 08/18] bpf: Add the bpf_scan_ir LLVM plugin Anton Protopopov
2026-11-06 21:02 ` [PATCH v1 bpf-next 09/18] bpf: Find fmod_ret candidates in bpf_scan_ir Anton Protopopov
2026-11-06 21:02 ` [PATCH v1 bpf-next 10/18] bpf: Allow writes to private stack objects " Anton Protopopov
2026-11-06 21:03 ` [PATCH v1 bpf-next 11/18] bpf: Follow PHIs " Anton Protopopov
2026-11-06 21:03 ` [PATCH v1 bpf-next 12/18] bpf: Follow integer casts " Anton Protopopov
2026-11-06 21:03 ` [PATCH v1 bpf-next 13/18] bpf: Check the return values of fmod_ret programs on found targets Anton Protopopov
2026-11-06 21:17   ` sashiko-bot
2026-11-09 13:14     ` Anton Protopopov
2026-11-09 13:16       ` Anton Protopopov
2026-11-06 21:03 ` [PATCH v1 bpf-next 14/18] bpf: Require the JIT for fmod_ret programs on found 64-bit targets Anton Protopopov
2026-11-06 21:03 ` [PATCH v1 bpf-next 15/18] resolve_btfids: Tag fmod_ret candidates as targets Anton Protopopov
2026-11-06 21:14   ` sashiko-bot
2026-11-09 13:26     ` Anton Protopopov
2026-11-06 21:50   ` bot+bpf-ci
2026-11-09 13:33     ` Anton Protopopov [this message]
2026-11-06 21:03 ` [PATCH v1 bpf-next 16/18] selftests/bpf: Test fmod_ret candidates found by bpf_scan_ir Anton Protopopov
2026-11-06 21:09   ` sashiko-bot
2026-11-09 14:09     ` Anton Protopopov
2026-11-06 21:50   ` bot+bpf-ci
2026-11-09 13:59     ` Anton Protopopov
2026-11-06 21:03 ` [PATCH v1 bpf-next 17/18] selftests/bpf: Enable bpf_scan_ir in the config Anton Protopopov
2026-11-06 21:35   ` bot+bpf-ci
2026-11-09 13:45     ` Anton Protopopov
2026-11-06 21:03 ` [PATCH v1 bpf-next 18/18] bpftool: List and show fmod_ret targets Anton Protopopov
2026-11-06 21:35   ` bot+bpf-ci
2026-11-09 13:40     ` Anton Protopopov
2026-11-09 17:02 ` [PATCH v1 bpf-next 01/18] bpf: Add BTF ID sets for " 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=avHLmNLouxZX5z-e@mail.gmail.com \
    --to=a.s.protopopov@gmail.com \
    --cc=almagui@kernel.org \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bot+bpf-ci@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brauner@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=emil@etsalapatis.com \
    --cc=ihor.solodrai@linux.dev \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@kernel.org \
    --cc=mason@kernel.org \
    --cc=memxor@gmail.com \
    --cc=qmo@kernel.org \
    --cc=sashal@kernel.org \
    --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 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.