From: "Florent Revest" <florent.revest@linux.dev>
To: <bot+bpf-ci@kernel.org>, <bpf@vger.kernel.org>, <ast@kernel.org>,
<daniel@iogearbox.net>, <andrii@kernel.org>
Cc: <martin.lau@linux.dev>, <eddyz87@gmail.com>, <memxor@gmail.com>,
<song@kernel.org>, <yonghong.song@linux.dev>, <jolsa@kernel.org>,
<kpsingh@kernel.org>, <john.fastabend@gmail.com>,
<leon.hwang@linux.dev>, <zirajs7@gmail.com>,
<rhkrqnwk98@gmail.com>, <puranjay@kernel.org>,
<xukuohai@huaweicloud.com>, <iii@linux.ibm.com>,
<hbathini@linux.ibm.com>, <chleroy@kernel.org>,
<naveen@kernel.org>, <bjorn@kernel.org>, <pulehui@huawei.com>,
<yangtiezhu@loongson.cn>, <hengqi.chen@gmail.com>,
<linux-kernel@vger.kernel.org>, <martin.lau@kernel.org>,
<eddyz87@gmail.com>, <yonghong.song@linux.dev>,
<mason@kernel.org>, <ihor.solodrai@linux.dev>
Subject: Re: [PATCH bpf v4 1/3] bpf: Wait for an RCU tasks grace period before freeing trampoline progs
Date: Sat, 26 Sep 2026 13:54:45 +0000 [thread overview]
Message-ID: <DLPAS1T6DHBE.LUGVFAKFRVSG@linux.dev> (raw)
In-Reply-To: <22e95dbf944bdf6b657249657e884617f79972a92430f17abd47c472797ec4ff@mail.kernel.org>
On Fri Sep 25, 2026 at 10:47 AM UTC, wrote:
> > diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> > index 1d2676782d70..d4f732996b47 100644
> > --- a/include/linux/bpf.h
> > +++ b/include/linux/bpf.h
> > @@ -1770,6 +1770,7 @@ struct bpf_prog_aux {
> > bool offload_requested; /* Program is bound and offloaded to the netdev. */
> > bool attach_btf_trace; /* true if attaching to BTF-enabled raw tp */
> > bool attach_tracing_prog; /* true if tracing another tracing program */
> > + bool tramp_linked; /* true if it was ever called from a trampoline */
> > bool func_proto_unreliable;
>
> Does this comment accurately describe when the flag is set?
>
> Looking at bpf_trampoline_add_prog() in kernel/bpf/trampoline.c, the
> flag is set at link time, right after hlist_add_head():
>
> hlist_add_head(&node->tramp_hlist, prog_list);
> node->link->prog->aux->tramp_linked = true;
>
> This happens before bpf_trampoline_update() has generated an image that
> could call the prog. If bpf_trampoline_update() then fails,
> __bpf_trampoline_link_prog() calls bpf_trampoline_remove_prog() and the
> flag stays true even though no trampoline ever called the prog.
>
> Setting the flag conservatively is correct for the free path, since it
> only adds an RCU Tasks grace period. But the comment describes a
> different condition than the one the code tracks. The field name and the
> commit message both say "linked to a trampoline".
>
> Would something like /* true if it was ever linked to a trampoline */
> match the code better, and stop a later reader from assuming the flag is
> only set once a trampoline image has actually run the prog?
Done in v5.
> [ ... ]
>
>
> ---
> 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/36122863248
next prev parent reply other threads:[~2026-09-26 13:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-25 10:03 [PATCH bpf v4 0/3] bpf: Fix use-after-free of progs detached from busy trampolines Florent Revest (Anthropic)
2026-09-25 10:03 ` [PATCH bpf v4 1/3] bpf: Wait for an RCU tasks grace period before freeing trampoline progs Florent Revest (Anthropic)
2026-09-25 10:47 ` bot+bpf-ci
2026-09-26 13:54 ` Florent Revest [this message]
2026-09-25 10:03 ` [PATCH bpf v4 2/3] bpf: Skip detached progs in trampoline images that are still in use Florent Revest (Anthropic)
2026-09-25 10:47 ` bot+bpf-ci
2026-09-26 8:44 ` Alexei Starovoitov
2026-09-26 13:52 ` Florent Revest
2026-09-26 13:54 ` Florent Revest
2026-09-25 10:03 ` [PATCH bpf v4 3/3] selftests/bpf: Detach a trampoline prog while a task sleeps before it Florent Revest (Anthropic)
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=DLPAS1T6DHBE.LUGVFAKFRVSG@linux.dev \
--to=florent.revest@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bjorn@kernel.org \
--cc=bot+bpf-ci@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=chleroy@kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=hbathini@linux.ibm.com \
--cc=hengqi.chen@gmail.com \
--cc=ihor.solodrai@linux.dev \
--cc=iii@linux.ibm.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=leon.hwang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@kernel.org \
--cc=martin.lau@linux.dev \
--cc=mason@kernel.org \
--cc=memxor@gmail.com \
--cc=naveen@kernel.org \
--cc=pulehui@huawei.com \
--cc=puranjay@kernel.org \
--cc=rhkrqnwk98@gmail.com \
--cc=song@kernel.org \
--cc=xukuohai@huaweicloud.com \
--cc=yangtiezhu@loongson.cn \
--cc=yonghong.song@linux.dev \
--cc=zirajs7@gmail.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.