Hi Alexei,
On Thu, Dec 21, 2023 at 10:07:33AM -0800, Alexei Starovoitov wrote:
> On Thu, Dec 21, 2023 at 9:43 AM Alan Maguire <alan.maguire@xxxxxxxxxx> wrote:
> >
> > On 21/12/2023 17:05, Alexei Starovoitov wrote:
> > > On Thu, Dec 21, 2023 at 12:35 AM Jiri Olsa <olsajiri@xxxxxxxxx> wrote:
> > >> you need to pick up only 'BTF_ID(func, ...)' IDs that belongs to SET8 lists,
> > >> which are bounded by __BTF_ID__set8__<name> symbols, which also provide size
> > >
> > > +1
> > >
> > >>>
> > >>> Maybe we need a codemod from:
> > >>>
> > >>> BTF_ID(func, ...
> > >>>
> > >>> to:
> > >>>
> > >>> BTF_ID(kfunc, ...
> > >>
> > >> I think it's better to keep just 'func' and not to do anything special for
> > >> kfuncs in resolve_btfids logic to keep it simple
> > >>
> > >> also it's going to be already in pahole so if we want to make a fix in future
> > >> you need to change pahole, resolve_btfids and possibly also kernel
> > >
> > > I still don't understand why you guys want to add it to vmlinux BTF.
> > > The kernel has no use in this additional data.
> > > It already knows about all kfuncs.
> > > This extra memory is a waste of space from kernel pov.
> > > Unless I am missing something.
> > >
> > > imo this logic belongs in bpftool only.
> > > It can dump vmlinux BTF and emit __ksym protos into vmlinux.h
> > >
> >
> > If the goal is to have bpftool detect all kfuncs, would having a BPF
> > kfunc iterator that bpftool could use to iterate over registered kfuncs
> > work perhaps?
>
> The kernel code ? Why ?
> bpftool can do the same thing as this patch. Iterate over set8 in vmlinux elf.
I think you're right for vmlinux -- bpftool can look at the elf file on
a running system. But I'm not sure it works for modules.
IIUC, the actual module ELF can go away while the kernel holds onto the
memory (as with initramfs). And even if that wasn't the case, in
containerized environments you may not be able to always see
/lib/modules or similar. That's assuming there's not a way to get the
module as with vmlinux /proc/kcore that I don't know about.
Looking at the tree, there's about 20k export symbols:
$ rg EXPORT_SYMBOL_GPL | wc -l
19471
Assuming kfuncs get there, that's about 312K of memory:
>>> (20000 * (12 + 4)) >> 10
312
So maybe a worthwhile tradeoff?
In general though, I kinda like having it in BTF cuz it's a structured
way to export metadata. IMO the link between kfuncs and BTF_ID_set8 is
kinda weak and might best be left as an implementation detail that
kernel devs can keep an eye on.
Thanks,
Daniel
