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

[Ihor Solodrai]

On 10/16/26 9:42 AM, Alexei Starovoitov wrote:
> On Fri, Oct 09, 2026 at 01:27 PM Ihor Solodrai <ihor.solodrai@xxxxxxxxx> wrote:
>> Introduce REF_TYPE_FRAME for this use case: a reference owned by a
>> callee frame, dropped when the frame is popped. Tie each argument to
>> this reference so callback return invalidates it and its descendants.
> 
> Another idea...
> The id is owned by the frame. Can we keep it in bpf_func_state
> like diag_frame_id ?
> release_reference() already takes ids that are not in refs[].
> See unmark_stack_slots_dynptr().
> Clones copy parent_id and slices hang off dynptr's id, so both are
> reached.

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.


> All setters have callee already, so no need for patches 1-3,
> REF_TYPE_FRAME, frameno in refs[], the reg that is its own parent, etc.

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?

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.

frame_id approach is fine with me, just want to understand the choices
we are making.

Thanks!

> [...]