Re: [RFC bpf-next 0/3] bpf: Introduce module helper functions

[Kumar Kartikeya Dwivedi <memxor@gmail.com>]

On Sat, Jan 22, 2022 at 04:18:13AM IST, Alexei Starovoitov wrote:
> On Fri, Jan 21, 2022 at 07:39:53PM +0000, Usama Arif wrote:
> > This patchset is a working prototype that adds support for calling helper
> > functions in eBPF applications that have been defined in a kernel module.
> >
> > It would require further work including code refractoring (not included in
> > the patchset) to rename functions, data structures and variables that are
> > used for kfunc as well to be appropriately renamed for module helper usage.
> > If the idea of module helper functions and the approach used in this patchset
> > is acceptable to the bpf community, I can send a follow up patchset with the
> > code refractoring included to make it ready for review.
> >
> > Module helpers are useful as:
> > - They support more argument and return types when compared to module
> > kfunc.
>
> What exactly is missing?
>

I looked at the set. I think the only difference between existing support and
this series is that you are using bpf_func_proto for argument checks, right? Is
there anything else it is adding?

We discussed whether to use bpf_func_proto for kfunc in [0], the conclusion was
that BTF has enough info that we don't have to use it. The only thing missing
is making the verifier assume type of argument from kernel BTF rather than
passed in argument register.

e.g. same argument can currently work with PTR_TO_BTF_ID and PTR_TO_MEM. On
Alexei's suggestion, we disabled the bad cases by limiting PTR_TO_MEM support
to struct with scalars. For current usecase that works fine.

I think once BTF tags are supported, we will be able to tag the function
argument as __arg_mem or __arg_btf_id and make the verifier more strict.
Same can be done for the return value (instead of ret_null_set as it is now).

  [0]: https://lore.kernel.org/bpf/20211105204908.4cqxk2nbkas6bduw@ast-mbp.dhcp.thefacebook.com/

> > - This adds a way to have helper functions that would be too specialized
> > for a specific usecase to merge upstream, but are functions that can have
> > a constant API and can be maintained in-kernel modules.
>
> Could you give an example of something that would be "too specialized" that
> it's worth maintaining in a module, but not worth maintaining in the kernel?
>
> Also see:
> https://www.kernel.org/doc/html/latest/bpf/bpf_design_QA.html#q-new-functionality-via-kernel-modules
>
> Why do you think we made that rule years ago?