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

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

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?