Re: [PATCH bpf-next v2 00/11] bpf: Scope callback arguments to their frame

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Tue, Oct 20, 2026 at 11:32 AM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
> Slices are not reached. A slice's parent_id is the dynptr id, and the
> walk from frame_id finds that id only while the dynptr is still in a
> register or a stack slot. R1 is caller-saved, so the bpf_dynptr_data()
> call that creates the slice usually clobbers it.
>
> This can be fixed in your diff with:
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index bc12df55d2e2..57859c3baeeb 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -11470,6 +11470,7 @@ void mark_frame_scoped_arg(struct bpf_verifier_env *env, struct bpf_func_state *
>  {
>  	if (!callee->frame_id)
>  		callee->frame_id = ++env->id_gen;
> +	callee->regs[regno].id = callee->frame_id;
>  	callee->regs[regno].parent_id = callee->frame_id;
>  }
>
> i.e. the reg is its own parent again.

got it. you're right. Let's take your one-liner.
I think the reg->id != id hunk can still stay out. The reg is
invalidated in the same pass, so the second pop of frame_id in
invalidate_reference() finds nothing and the loop ends.

> I don't quite understand the concern with the series as is.
> I'm guessing a new weird REF_TYPE in refs[] which is not an actual
> acquirable object gives an ick. Or is it the plumbing?
> I take it you agree that we need some kind of frame-tied lifetime
> tracking, right?

Yes, we need it. I guess it's the plumbing that bothers me a bit.
The id belongs to the frame, but refs[] is in bpf_verifier_state and
the callback runs in a pushed state. That's why setters had to move
out of setup_func_entry(), take a state argument and handle errors,
and why refsafe() and check_reference_leak() need REF_TYPE_FRAME
cases. A u32 in the frame needs none of that.

> I added some refactoring patches in attempt to avoid growing
> bpf_func_state vs v1 (Eduard mentioned we create a lot of these
> objects), and that is what you've just suggested.

Right, it grows. With padding that's 8 bytes on a 960 byte struct,
880 of which is regs[]. I feel it's cheaper than patches 1-3,
but I don't insist.