Re: [PATCH bpf-next 1/3] bpf: support nocsr patterns for calls to kfuncs

[Eduard Zingerman <eddyz87@gmail.com>]

On Thu, 2024-08-15 at 15:23 -0700, Yonghong Song wrote:
> On 8/15/24 3:07 PM, Eduard Zingerman wrote:
> > On Thu, 2024-08-15 at 14:24 -0700, Andrii Nakryiko wrote:
> > 
> > [...]
> > 
> > > > @@ -16140,6 +16140,28 @@ static bool verifier_inlines_helper_call(struct bpf_verifier_env *env, s32 imm)
> > > >          }
> > > >   }
> > > > 
> > > > +/* Same as helper_nocsr_clobber_mask() but for kfuncs, see comment above */
> > > > +static u32 kfunc_nocsr_clobber_mask(struct bpf_kfunc_call_arg_meta *meta)
> > > > +{
> > > > +       const struct btf_param *params;
> > > > +       u32 vlen, i, mask;
> > > > +
> > > > +       params = btf_params(meta->func_proto);
> > > > +       vlen = btf_type_vlen(meta->func_proto);
> > > > +       mask = 0;
> > > > +       if (!btf_type_is_void(btf_type_by_id(meta->btf, meta->func_proto->type)))
> > > > +               mask |= BIT(BPF_REG_0);
> > > > +       for (i = 0; i < vlen; ++i)
> > > > +               mask |= BIT(BPF_REG_1 + i);
> > > Somewhere deep in btf_dump implementation of libbpf, there is a
> > > special handling of `<whatever> func(void)` (no args) function as
> > > having vlen == 1 and type being VOID (i.e., zero). I don't know if
> > > that still can happen, but I believe at some point we could get this
> > > vlen==1 and type=VOID for no-args functions. So I wonder if we should
> > > handle that here as well, or is it some compiler atavism we can forget
> > > about?
> > > 
> > I just checked BTF generated for 'int filelock_init(void)',
> > for gcc compiled kernel using latest pahole and func proto looks as follows:
> > 
> >    FUNC_PROTO '(anon)' ret_type_id=12 vlen=0
> > 
> > So I assume this is an atavism.
> 
> Agree, for kernel vmlinux BTF, we should be fine.

Right, since we are dealing only with vmlinux BTF special case is not needed.
Please let me know if I misunderstand you or Andrii.