Re: [PATCH bpf-next v3 0/9] Refactor verifier object relationship tracking

Amery Hung
2026-04-24T16:19:33Z

On Fri, Apr 24, 2026 at 7:03 AM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Thu Apr 23, 2026 at 10:44 PM PDT, Amery Hung wrote:
> > On Thu, Apr 23, 2026 at 5:55 PM Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> wrote:
> >>
> >> On Tue Apr 21, 2026 at 3:10 PM PDT, Amery Hung wrote:
> >> >
> >> > (3) Referenced dynptr with referenced parent:
> >> >
> >> > file (1,1,0)
> >> > ^ ^
> >> > bpf_dynptr_from_file | +-------------------------------+
> >> > | bpf_dynptr_clone(A, C) |
> >> > dynptr A (2,3,1) dynptr C (4,3,1)
> >> > ^ ^
> >> > | |
> >> > dynptr A and C have the same lifetime
> >>
> >> If I understand the proposal correctly above should be:
> >>
> >> file (1,0,0)
> >> ^
> >> bpf_dynptr_from_file +-------------------------------+
> >>
> >> ref_obj_id will be inited bpf_dynptr_clone() as 3 into A and C.
> >> but original file->ref_obj_id will be zero.
> >>
> >> ?
> >
> > This is the existing behavior. bpf_get_task_exe_file() is tagged with
> > (KF_ACQUIRE | KF_RET_NULL). Therefore, file will have id and
> > ref_obj_id both initialized to the same value. Here is the
> > corresponding verifier code:
> >
> > if (is_kfunc_acquire(&meta)) {
> > int id = acquire_reference(env, insn_idx);
> >
> > if (id < 0)
> > return id;
> > if (is_kfunc_ret_null(&meta))
> > regs[BPF_REG_0].id = id;
> > regs[BPF_REG_0].ref_obj_id = id;
>
> ok, but the arrow should still point to first '1', since that's
> what parent_id inherits?

Ohh yes. I totally missed the error. Thanks for pointing out.