On Wed, Jul 13, 2022 at 5:13 AM Kumar Kartikeya Dwivedi <memxor@xxxxxxxxx> wrote: > > > Ahh. Now I remember. Thanks for reminding :) > > > Could you please summarize this thread and add all of it as a big comment > > > in the source code next to __ref handling to explain the motivation > > > and an example on when and how this __ref suffix should be used. > > > Otherwise somebody, like me, will forget the context soon. > > > > > > I was thinking of better name than __ref, but couldn't come up with one. > > > __ref fits this use case the best. > > > > Actually, maybe a kfunc flag will be better? > > Like REF_ARGS > > that would apply to all arguments of the kfunc > > (not only those with __ref suffix). > > > > We have three types of ptr_btf_id: > > - ref counted > > - untrusted > > - old legacy that we cannot be break due to backward compat > > > > In the future we'll probably be adding new kfuncs where we'd want > > every argument to be trusted. In our naming convention these are > > the refcounted ptr_to_btf_id that come from lookup-like kfuncs. > > To consume them in the release kfunc they have to be refcounted, > > but non-release kfunc (like set_timeout) also want a trusted ptr. > > So the simple way of describe the intent would be: > > BTF_ID(func, bpf_ct_release, RELEASE) > > BTF_ID(func, bpf_ct_set_timeout, REF_ARGS) > > > > or maybe TRUSTED_ARGS would be a better flag name. > > wdyt? > > Ok, I've implemented the kfunc flags and kept TRUSTED_ARGS as the > name. Just need to do a little bit of testing and will post it > together with this. Awesome! > Just to confirm, should I still keep __ref or drop it? I think > TRUSTED_ARGS has its use but it may be too coarse. I already have the > patch so if you like we can add both ways now. TRUSTED_ARGS may become too coarse, but let's cross that bridge when there is actual need. If we land __ref support right now there won't be any users and the code will start to bit rot. So let's delay it. Pls post that patch as an extra RFC patch anyway, so it won't get lost.
