From: Yonghong Song <yonghong.song@linux.dev>
To: bot+bpf-ci@kernel.org, bpf@vger.kernel.org
Cc: ast@kernel.org, andrii@kernel.org, daniel@iogearbox.net,
eddyz87@gmail.com, kernel-team@fb.com, martin.lau@kernel.org,
mason@kernel.org, ihor.solodrai@linux.dev
Subject: Re: [PATCH bpf-next v8 08/22] bpf: Require an unwind to leave a frame holding what it entered with
Date: Fri, 2 Oct 2026 22:10:18 +0100 [thread overview]
Message-ID: <f6bd483c-a6ec-41f0-87cc-771cea8cf38d@linux.dev> (raw)
In-Reply-To: <a203a496c37cc672ef89f2e95a82b48c4a19863d832a055a3bfda60e3fd206ec@mail.kernel.org>
On 10/1/26 7:31 AM, bot+bpf-ci@kernel.org wrote:
>> bpf: Require an unwind to leave a frame holding what it entered with
> TL;DR: call_may_unwind() treats every callx as possibly unwinding, so the
> verifier may wrongly reject valid programs that hold a reference or spin lock
> across a callx; the exact target is available from the register.
>
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> index c7a350be538e..a7b25ab04051 100644
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
> [ ... ]
>
>> @@ -19244,6 +19245,32 @@ static int unwind_out_of_global_call(struct bpf_verifier_env *env, int call_idx,
>> return INSN_IDX_UPDATED;
>> }
>>
>> +/* Can an unwind come back out of this call? */
>> +static bool call_may_unwind(struct bpf_verifier_env *env, const struct bpf_insn *insn,
>> + int insn_idx)
>> +{
>> + int subprog;
>> +
>> + /* Which subprog a callx lands in is not known here, so any may be it. */
>> + if (bpf_is_callx(insn))
>> + return bpf_prog_may_unwind(env);
> Is it true that the target of a callx is not known here?
This is way to conservatile as if *any* subprog is marked as may_unwind, then
it will return bpf_is_callx(insn). The best thing is to follow callx itself
and find whether it is possible may_unwind or not.
>
> call_may_unwind() is reached from check_unwind_through_call() in
> do_check_insn(), just before check_func_callx(). check_func_callx() takes
> the exact target from the same register state a few lines later:
>
> reg = reg_state(env, insn->dst_reg);
> if (reg->type != PTR_TO_FUNC) ...
> /* PTR_TO_FUNC is a pointer to a static subprog */
> subprog = reg->subprogno;
>
> and check_func_ptr_read() pushes one state per possible table target, each
> with its own subprogno. So each verified callx has exactly one target at
> this point. Only the CFG pass has to be conservative, and
> mark_callx_might_unwind() already marks any target that itself contains a
> callx.
>
> With the current code, an uncovered callx is refused by
> bpf_exc_check_frame_balance() whenever the calling frame has changed its
> RCU, preempt, IRQ, spin lock or reference state since entry, as long as some
> unrelated subprog in the program is marked might_unwind. For example:
>
> foo():
> t = bpf_task_acquire(...); /* id > entry_id_gen */
> r1 = vtable[i]; /* PTR_TO_FUNC -> bar, no unwind in bar */
> callx r1 /* no cleanup record covers it */
> bpf_task_release(t);
>
> baz():
> bpf_unwind(); /* makes bpf_prog_may_unwind() true */
>
> Before this patch this program was accepted. Now it is refused with "an
> unwind through this call keeps the reference id=N the frame acquired", even
> though no unwind can pass through that call. callx is also explicitly
> allowed under a spin lock, so a frame that holds a bpf_spin_lock across a
> callx is refused as well with "an unwind through this call does not leave
> the frame's bpf_spin_lock state as it found it".
>
> Could this look at the register instead, something like:
>
> reg = &cur_regs(env)[insn->dst_reg];
> if (reg->type == PTR_TO_FUNC)
> return env->subprog_info[reg->subprogno].might_unwind;
>
> and leave it to check_func_callx() to refuse any other register type, as it
> does today?
>
>> + if (insn->src_reg != BPF_PSEUDO_CALL)
>> + return false;
>> + subprog = bpf_find_subprog(env, insn_idx + insn->imm + 1);
>> + return subprog >= 0 && env->subprog_info[subprog].might_unwind;
>> +}
>> +
> [ ... ]
>
>
> ---
> 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/36872142096
next prev parent reply other threads:[~2026-10-02 21:10 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-01 13:30 [PATCH bpf-next v8 00/22] bpf: Run exception cleanup landing pads when bpf_unwind() unwinds Yonghong Song
2026-10-01 13:30 ` [PATCH bpf-next v8 01/22] bpf: Pack bpf_insn_aux_data flags into bit fields Yonghong Song
2026-10-01 13:30 ` [PATCH bpf-next v8 02/22] bpf: Accept the compiler's exception cleanup table at program load Yonghong Song
2026-10-01 13:30 ` [PATCH bpf-next v8 03/22] bpf: Add the bpf_unwind() and bpf_unwind_resume() kfuncs Yonghong Song
2026-10-01 13:30 ` [PATCH bpf-next v8 04/22] bpf: Add lookups for exception cleanup resumes and landing pads Yonghong Song
2026-10-01 13:48 ` sashiko-bot
2026-10-02 18:17 ` Yonghong Song
2026-10-01 13:30 ` [PATCH bpf-next v8 05/22] bpf: Prepare for an exception cleanup table before the CFG walk Yonghong Song
2026-10-01 14:31 ` bot+bpf-ci
2026-10-02 19:06 ` Yonghong Song
2026-10-01 13:30 ` [PATCH bpf-next v8 06/22] bpf: Make exception landing pads reachable in the CFG Yonghong Song
2026-10-01 13:30 ` [PATCH bpf-next v8 07/22] bpf: Follow an unwind to its landing pad in the verifier Yonghong Song
2026-10-01 13:50 ` sashiko-bot
2026-10-02 19:31 ` Yonghong Song
2026-10-01 14:31 ` bot+bpf-ci
2026-10-02 20:49 ` Yonghong Song
2026-10-03 12:23 ` Alexei Starovoitov
2026-10-04 17:56 ` Yonghong Song
2026-10-01 13:30 ` [PATCH bpf-next v8 08/22] bpf: Require an unwind to leave a frame holding what it entered with Yonghong Song
2026-10-01 14:31 ` bot+bpf-ci
2026-10-02 21:10 ` Yonghong Song [this message]
2026-10-03 12:25 ` Alexei Starovoitov
2026-10-04 17:59 ` Yonghong Song
2026-10-01 13:30 ` [PATCH bpf-next v8 09/22] bpf: Refuse a landing pad that does not resume Yonghong Song
2026-10-03 12:25 ` Alexei Starovoitov
2026-10-04 18:26 ` Yonghong Song
2026-10-01 13:30 ` [PATCH bpf-next v8 10/22] bpf: Do not use a private stack for a program that can unwind Yonghong Song
2026-10-01 13:53 ` sashiko-bot
2026-10-02 21:38 ` Yonghong Song
2026-10-01 13:31 ` [PATCH bpf-next v8 11/22] bpf: Dispatch cleanup pads by rewriting return addresses Yonghong Song
2026-10-01 14:31 ` bot+bpf-ci
2026-10-02 21:48 ` Yonghong Song
2026-10-03 12:26 ` Alexei Starovoitov
2026-10-04 18:28 ` Yonghong Song
2026-10-04 18:29 ` Yonghong Song
2026-10-01 13:31 ` [PATCH bpf-next v8 12/22] bpf, x86: Dispatch exception cleanup pads at run time Yonghong Song
2026-10-01 13:49 ` sashiko-bot
2026-10-02 21:54 ` Yonghong Song
2026-10-01 13:31 ` [PATCH bpf-next v8 13/22] bpf, arm64: " Yonghong Song
2026-10-01 13:31 ` [PATCH bpf-next v8 14/22] libbpf: Resolve the compiler's _Unwind_Resume to the kernel's kfunc Yonghong Song
2026-10-01 13:31 ` [PATCH bpf-next v8 15/22] libbpf: Add cleanup_info to bpf_prog_load_opts Yonghong Song
2026-10-01 13:46 ` sashiko-bot
2026-10-02 22:09 ` Yonghong Song
2026-10-01 13:31 ` [PATCH bpf-next v8 16/22] libbpf: Collect .bpf_cleanup records and pass them to the kernel Yonghong Song
2026-10-01 13:31 ` [PATCH bpf-next v8 17/22] libbpf: Carry the exception cleanup table through the light skeleton Yonghong Song
2026-10-01 13:31 ` [PATCH bpf-next v8 18/22] libbpf: Let the static linker carry .bpf_cleanup relocations Yonghong Song
2026-10-01 13:31 ` [PATCH bpf-next v8 19/22] selftests/bpf: Add end-to-end and negative .bpf_cleanup exception tests Yonghong Song
2026-10-01 13:31 ` [PATCH bpf-next v8 20/22] selftests/bpf: Add __set_global() and __ret_global() test tags Yonghong Song
2026-10-01 13:31 ` [PATCH bpf-next v8 21/22] selftests/bpf: Cover more accepted .bpf_cleanup exception shapes Yonghong Song
2026-10-01 13:32 ` [PATCH bpf-next v8 22/22] 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=f6bd483c-a6ec-41f0-87cc-771cea8cf38d@linux.dev \
--to=yonghong.song@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bot+bpf-ci@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=ihor.solodrai@linux.dev \
--cc=kernel-team@fb.com \
--cc=martin.lau@kernel.org \
--cc=mason@kernel.org \
/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.