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

Alexei Starovoitov
2026-04-24T13:55:19Z

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?