Re: [PATCH bpf-next v2 0/5] execmem_alloc for BPF programs

[Song Liu <song@kernel.org>]

On Wed, Nov 16, 2022 at 1:22 PM Edgecombe, Rick P
<rick.p.edgecombe@intel.com> wrote:
>
> On Tue, 2022-11-15 at 17:20 -0800, Song Liu wrote:
> > To clarify, are you suggesting we need this logic in this set? I
> > would
> > rather wait until we handle module code. This is because BPF JIT uses
> > module_alloc() for archs other than x86_64. So the fall back of
> > execmem_alloc() for these archs would be module_alloc() or
> > something similar. I think it is really weird to do something like
> >
> > void *execmem_alloc(size_t size)
> > {
> > #ifdef CONFIG_SUPPORT_EXECMEM_ALLOC
> >     ...
> > #else
> >     return module_alloc(size);
> > #endif
> > }
> >
> > WDYT?
>
> Hmm, that is a good point. It looks like it's plugged in backwards.
>
> Several people in the past have expressed that all the text users
> calling into *module*_alloc() also is a little wrong. So I think in
> some finished future, each architecture would have an execmem_alloc()
> arch breakout of some sort that modules could use instead of it's
> module_alloc() logic. So basically all the module_alloc() arch
> specifics details of location and PAGE_FOO would move to execmem.
>
> I guess the question is how to get there. Calling into module_alloc()
> does the job but looks wrong. There are a lot of module_alloc()s, but
> what about implementing an execmem_alloc() for each bpf jit
> architecture that doesn't match the existing default version. It
> shouldn't be too much code. I think some of them will work with just
> the  EXEC_MEM_START/END heuristic and wont need a breakout.
>
> But if this thing just works for x86 BPF JITs, I'm not sure we can say
> we have unified anything...

powerpc BPF JIT is getting bpf_prog_pack soon. [1] And we should
be able to make ftrace and BPF trampoline to use execmem_alloc
soon after this set is merged. AFAICT, we don't have to finalize the
API until we handle module text. I personally think current API is
good enough for ftrace and BPF trampoline, which already use
something similar to JIT.

Thanks,
Song

[1] https://lore.kernel.org/bpf/20221110184303.393179-1-hbathini@linux.ibm.com/