On Tue, Oct 18, 2022 at 07:23:23AM +0530, Kumar Kartikeya Dwivedi wrote: Note: I'm responding to Kumar's email from v3 [0] here on v5 instead, per his request on [1]. [0]: https://lore.kernel.org/all/CAP01T77PTK+bD2mBrxJShKNPhEypT2+nSHcr3=uuJbrghv_wFg@xxxxxxxxxxxxxx/ [1]: https://lore.kernel.org/all/CAP01T747PKC2jySOZCWu_gauHbBfaj4JE=hbtm4Z4C-Y8b3ZHg@xxxxxxxxxxxxxx/ My apologies again for the silly mistakes and having to send multiple versions of the patch set. > On Sat, 15 Oct 2022 at 01:45, David Vernet <void@xxxxxxxxxxxxx> wrote: > > > > A previous change added a series of kfuncs for storing struct > > task_struct objects as referenced kptrs. This patch adds a new > > task_kfunc test suite for validating their expected behavior. > > > > Signed-off-by: David Vernet <void@xxxxxxxxxxxxx> > > --- > > [...] > > + > > +SEC("tp_btf/task_newtask") > > +int BPF_PROG(task_kfunc_acquire_trusted_nested, struct task_struct *task, u64 clone_flags) > > +{ > > + struct task_struct *acquired; > > + > > + if (!is_test_kfunc_task()) > > + return 0; > > + > > + /* Can't invoke bpf_task_acquire() on a trusted pointer at a nonzero offset. */ > > + acquired = bpf_task_acquire(task->last_wakee); > > The comment is incorrect, that would be &task->last_wakee instead, > this is PTR_TO_BTF_ID | PTR_NESTED. Well, it's a nonzero offset from task. But yes, to your point, it's a misleading comment because the offset is 0 in the verifier. I'll rephrase this to reflect that it's a nested pointer (or a walked pointer, whatever nomenclature we end up going with). > > + if (!acquired) > > + return 0; > > + bpf_task_release(acquired); > > + > > + return 0; > > +} > > + > > [...] > > + > > +static int test_acquire_release(struct task_struct *task) > > +{ > > + struct task_struct *acquired; > > + > > + acquired = bpf_task_acquire(task); > > Unfortunately a side effect of this change is that now since > PTR_TO_BTF_ID without ref_obj_id is considered trusted, the bpf_ct_* > functions would begin working with tp_btf args. That probably needs > be fixed so that they reject them (ideally with a failing test case to > make sure it doesn't resurface), probably with a new suffix __ref/or > __owned as added here [0]. > > Alexei, since you've suggested avoiding adding that suffix, do you see > any other way out here? > It's questionable whether bpf_ct_set_timeout/status should work for CT > not owned by the BPF program. > > [0]: https://lore.kernel.org/bpf/dfb859a6b76a9234baa194e795ae89cb7ca5694b.1662383493.git.lorenzo@kerne Ah, yeah, it makes sense that some kfuncs really should only ever be passed an object if the program owns a reference on it. Specifically for e.g. bpf_ct_set_timeout/status() as you point out, which should only be passed a struct nf_conn__init that was allocated by bpf_skb_ct_alloc(). It'd be nice if we could just add another flag like KF_REFERENCED_ARGS or KF_OWNED_ARGS, which would allow a subset of arguments affored by KF_TRUSTED_ARGS, only those with ref_obj_id > 0. That approach wouldn't allow the flexibility of having per-argument specifications as your proposal to use __ref or __owned suffixes on the names, but that already applies to KF_TRUSTED_ARGS as well. Personally I'm in agreement with Alexei that it's not a user friendly API to use suffixes in the name like this. If we want to allow kfunc authors to have per-argument specifiers, using compiler attributes and/or some kind of tagging is probably the way to do it? My proposal for now is to add a new KF_OWNED_ARGS flag, and to very clearly document exactly what that and KF_TRUSTED_ARGS implies for kfuncs. Later on, we could explore solutions for having per-arg specifiers. What do you and Alexei think?
