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

[Mike Rapoport <rppt@kernel.org>]

On Mon, Nov 14, 2022 at 12:30:49PM -0800, Song Liu wrote:
> On Sun, Nov 13, 2022 at 2:35 AM Mike Rapoport <rppt@kernel.org> wrote:
> >
> > My concern is that the proposed execmem_alloc() cannot be used for
> > centralized handling of loading text. I'm not familiar enough with
> > modules/ftrace/kprobes/BPF to clearly identify the potential caveats, but
> > my gut feeling is that the proposed execmem_alloc() won't be an improvement
> > but rather a hindrance for moving to centralized handling of loading text.
> 
> I don't follow why this could ever be a hindrance. Luis is very excited about
> this, and I am very sure it works for ftrace, kprobe, and BPF.

Again, it's a gut feeling. But for execmem_alloc() to be a unified place of
code allocation, it has to work for all architectures. If architectures
have to override it, then where is the unification?

The implementation you propose if great for x86, but to see it as unified
solution it should be good at least for the major architectures.

> > It feels to me that a lot of ground work is needed to get to the point
> > where we can use centralized handling of loading text.
> 
> Could you please be more specific on what is needed?

The most obvious one to implement Peter's suggestion with VM_TOPDOWN_VMAP
so that execmem_alloc() can be actually used by modules.
 
> Thanks,
> Song

-- 
Sincerely yours,
Mike.