From: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
To: "Kumar Kartikeya Dwivedi" <memxor@gmail.com>,
"Eduard Zingerman" <eddyz87@gmail.com>,
"Yonghong Song" <yonghong.song@linux.dev>, <bpf@vger.kernel.org>
Cc: "Alexei Starovoitov" <ast@kernel.org>,
"Andrii Nakryiko" <andrii@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>, <kernel-team@fb.com>
Subject: Re: [PATCH bpf-next v5 07/21] bpf: Explore the landing pads no call site reaches
Date: Thu, 24 Sep 2026 01:53:41 +0000 [thread overview]
Message-ID: <DLN66VIA4CPY.1HCNCKTWC3JX@gmail.com> (raw)
In-Reply-To: <DLN42F6YUPGB.25WMDJLB3IJJF@gmail.com>
On Thu Sep 24, 2026 at 12:13 AM UTC, Kumar Kartikeya Dwivedi wrote:
> On Thu Sep 24, 2026 at 1:20 AM CEST, Alexei Starovoitov wrote:
>> On Wed Sep 23, 2026 at 10:19 PM UTC, Eduard Zingerman wrote:
>>> On Wed, 2026-09-23 at 21:28 +0000, Alexei Starovoitov wrote:
>>>
>>> ...
>>>
>>>> imo the following is cleaner:
>>>> - do not repurpose bpf_throw() for this new thing.
>>>> Introduce new kfunc that will do the unwind, let's name it bpf_unwind() ?
>>>> - replace all 'call bpf_unwind_resume' with NOP by the verifier (or may with bpf_exit. tbd)
>>>> Technically rustc or llvm can do that too, but it's cleaner to do in the verifier.
>>>> - In bpf_unwind() walk all exception tables and replace return addresses
>>>> in corresponding frames to landing_pad_ip-s.
>>>> - just return from bpf_unwind().
>>>> restoring callee saved registers will happen automatically by corresponding
>>>> frames and there is no need to search exception tables at each step.
>>>> That's what typical eh unwinder does, but it's doing it due to C++ logic
>>>> that is more complex that Rust. For Rust unwinds we don't need all that.
>>>> The above algorithm will do.
>>>
>>> +1, makes sense.
>>> After return address rewrite the unwind would have to jump to it's epilogue, right?
>>
>> yes. I feel there will be no need in asm() tricks in such kfunc.
>> unwind will rewrite its own return address, and will return through normal C
>> and will restore callee saved (whatever it needed),
>> then immediate callee in bpf prog should have had a landing pad for this kfunc,
>> since this kfunc is throwing.
>> so bpf_unwind() will jump to whatever is necessary to unwind in that bpf prog.
>> And so on till the end.
>>
>>> Why not reusing bpf_throw() though, is it because of the exception cb mechanics?
>>
>> yes. bpf_throw() is not seen as throwing from compiler pov.
>> I believe all kfuncs are not throwing. (that was a bug in this patch I alluded earlier).
>> So we need a new kfunc and mark it attr(may_throw) or whatever the attr is called,
>> so that compiler will generate exception tables for that bpf prog.
>> Last time I checked there were bpf_cleanup section for rust-c in that case,
>> but that was back in April.
>
> Hm, isn't this dependent on how you annotate the kfunc on the Rust side? Like,
> you could make the same annotation on bpf_throw() that you would for the new
> kfunc, no? I got confused by this part.
bpf_throw() has a specific semantic already.
Like it suppose to call that bpf prog callback once it unwinds
everything.
This new kfunc is different. It will initiate the unwind the way rust wants it to
and may stop in the middle.
See below point about 'catching'.
>> There is also a case of 'catching' abort in rust. iirc it only stops unwind and
>> rust-c generates something else instead of 'call bpf_unwind_resume'.
>> Memory is vague. I think that frame will continue as normal after processing
>> landing pad drop()s.
next prev parent reply other threads:[~2026-09-24 1:53 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 4:58 [PATCH bpf-next v5 00/21] bpf: Run exception cleanup landing pads when bpf_throw() unwinds Yonghong Song
2026-09-23 4:58 ` [PATCH bpf-next v5 01/21] bpf: Pack bpf_insn_aux_data flags into bit fields Yonghong Song
2026-09-23 5:40 ` bot+bpf-ci
2026-09-23 19:16 ` Eduard Zingerman
2026-09-23 4:58 ` [PATCH bpf-next v5 02/21] bpf: Accept the compiler's exception cleanup table at program load Yonghong Song
2026-09-23 4:59 ` [PATCH bpf-next v5 03/21] bpf: Add the bpf_unwind_resume() kfunc Yonghong Song
2026-09-23 6:13 ` Kumar Kartikeya Dwivedi
2026-09-23 4:59 ` [PATCH bpf-next v5 04/21] bpf: Add lookups for exception cleanup resumes and landing pads Yonghong Song
2026-09-23 4:59 ` [PATCH bpf-next v5 05/21] bpf: Prepare for an exception cleanup table before the CFG walk Yonghong Song
2026-09-23 5:40 ` bot+bpf-ci
2026-09-23 4:59 ` [PATCH bpf-next v5 06/21] bpf: Make exception landing pads reachable in the CFG Yonghong Song
2026-09-23 5:51 ` bot+bpf-ci
2026-09-23 19:25 ` Eduard Zingerman
2026-09-23 4:59 ` [PATCH bpf-next v5 07/21] bpf: Explore the landing pads no call site reaches Yonghong Song
2026-09-23 16:26 ` Eduard Zingerman
2026-09-23 17:27 ` Yonghong Song
2026-09-23 18:06 ` Eduard Zingerman
2026-09-23 18:09 ` Yonghong Song
2026-09-23 21:28 ` Alexei Starovoitov
2026-09-23 22:19 ` Eduard Zingerman
2026-09-23 23:20 ` Alexei Starovoitov
2026-09-24 0:13 ` Kumar Kartikeya Dwivedi
2026-09-24 1:53 ` Alexei Starovoitov [this message]
2026-09-24 6:12 ` Kumar Kartikeya Dwivedi
2026-09-23 23:09 ` Yonghong Song
2026-09-23 4:59 ` [PATCH bpf-next v5 08/21] bpf: Walk the exception unwind in the verifier Yonghong Song
2026-09-23 16:34 ` Eduard Zingerman
2026-09-23 18:01 ` Yonghong Song
2026-09-23 4:59 ` [PATCH bpf-next v5 09/21] bpf: Refuse exception cleanup shapes bpf_throw() cannot dispatch Yonghong Song
2026-09-23 4:59 ` [PATCH bpf-next v5 10/21] bpf: Refuse a private stack for a program with an exception cleanup table Yonghong Song
2026-09-23 4:59 ` [PATCH bpf-next v5 11/21] bpf: Dispatch exception cleanup pads from bpf_throw() Yonghong Song
2026-09-23 4:59 ` [PATCH bpf-next v5 12/21] bpf, x86: Dispatch exception cleanup pads at run time Yonghong Song
2026-09-23 6:45 ` Eduard Zingerman
2026-09-23 20:45 ` Yonghong Song
2026-09-23 4:59 ` [PATCH bpf-next v5 13/21] bpf, arm64: " Yonghong Song
2026-09-23 4:59 ` [PATCH bpf-next v5 14/21] libbpf: Resolve the compiler's _Unwind_Resume to the kernel's kfunc Yonghong Song
2026-09-23 8:36 ` Kumar Kartikeya Dwivedi
2026-09-23 5:00 ` [PATCH bpf-next v5 15/21] libbpf: Add cleanup_info to bpf_prog_load_opts Yonghong Song
2026-09-23 5:00 ` [PATCH bpf-next v5 16/21] libbpf: Collect .bpf_cleanup records and pass them to the kernel Yonghong Song
2026-09-23 5:52 ` Kumar Kartikeya Dwivedi
2026-09-23 5:00 ` [PATCH bpf-next v5 17/21] libbpf: Carry the exception cleanup table through the light skeleton Yonghong Song
2026-09-23 5:00 ` [PATCH bpf-next v5 18/21] libbpf: Let the static linker carry .bpf_cleanup relocations Yonghong Song
2026-09-23 5:40 ` bot+bpf-ci
2026-09-23 5:00 ` [PATCH bpf-next v5 19/21] selftests/bpf: Add an end-to-end .bpf_cleanup exception test Yonghong Song
2026-09-23 5:51 ` bot+bpf-ci
2026-09-23 5:00 ` [PATCH bpf-next v5 20/21] selftests/bpf: Cover the exception cleanup shapes the chain does not reach Yonghong Song
2026-09-23 5:51 ` bot+bpf-ci
2026-09-23 7:50 ` Eduard Zingerman
2026-09-23 5:00 ` [PATCH bpf-next v5 21/21] selftests/bpf: Load an exception cleanup program from a light skeleton Yonghong Song
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=DLN66VIA4CPY.1HCNCKTWC3JX@gmail.com \
--to=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=kernel-team@fb.com \
--cc=memxor@gmail.com \
--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