Re: [PATCH bpf-next v4 07/20] bpf: Refuse exception cleanup shapes bpf_throw() cannot dispatch

[Eduard Zingerman <eddyz87@gmail.com>]

On Mon, 2026-09-21 at 14:01 -0700, Yonghong Song wrote:
> The table is on the instructions and the landing pads are in the control
> flow graph. What is left before bpf_throw() can be taught to dispatch them
> is to work out what that walk will need, and refuse the shapes it could not
> handle.
> 
> bpf_check_cleanup_exceptions() runs after bpf_check_cfg(). Everything it
> needs is control flow, so it reads what that walk has already worked out
> rather than working it out again:
> 
>   subprog_info.might_throw   which subprograms an exception may leave,
>                              closed over the call graph by
>                              merge_callee_effects() as the walk pops each
>                              callee
>   cleanup_reachability()     what each instruction can reach -- a resume, a
>                              plain exit, a throw, an indirect jump
>   cleanup_mark_pad_bodies()  which instructions only ever run with an
>                              exception already in flight
> 
> What it refuses:
> 
>   - a pad that reaches both a resume and a plain exit, or neither: nothing
>     says whether it is a cleanup pad or a catch pad
>   - a catch pad, which ends in a plain exit: the walker calls a pad as a
>     subroutine and cannot hand a frame back its own execution
>   - a throw in a pad, or a call from a pad to a subprogram that can throw:
>     a second unwind over frames the first is still discarding
>   - a bpf_unwind_resume() outside a pad body
>   - a subprogram that may unwind used as a helper callback: the helper's
>     own kernel frame would end the walk before it found a boundary
>   - a tail call, an indirect jump, or an outgoing on-stack call argument in
>     a pad body, all of which touch a stack the pad does not own
>   - a BPF_LD_[ABS|IND] in a pad body: a failed load leaves the subprogram
>     through the hidden exit gen_ld_abs() patches in, and an exit in a pad
>     is the epilogue, which pops off the walker's stack and returns through
>     the frame the walk is discarding
> 
> Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
> ---

Why is it necessary to hand-roll a CFG traversal and a separate pass
for this check? Given that bpf verifier state already maintains
`unwinding' flag, the instructions properties can be checked from
do_check_insn(), e.g.:
- bpf_throw()               -- reject if unwinding
- call to a throwing global -- reject if unwinding
- bpf_unwind_resume()       -- require unwinding and the pad-owning frame
- BPF_EXIT                  -- reject in the pad-owning frame, allow in callees
- LD_{ABS,IND}              -- reject if unwinding

I think that would take much less code, wdyt?

>  include/linux/bpf_verifier.h |   1 +
>  kernel/bpf/exception.c       | 404 +++++++++++++++++++++++++++++++++++
>  kernel/bpf/exception.h       |   2 +
>  kernel/bpf/fixups.c          |   1 +
>  kernel/bpf/verifier.c        |   8 +
>  5 files changed, 416 insertions(+)

...