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

[Song Liu <song@kernel.org>]

On Sun, Nov 13, 2022 at 2:35 AM Mike Rapoport <rppt@kernel.org> wrote:
>
> On Wed, Nov 09, 2022 at 05:04:25PM +0000, Edgecombe, Rick P wrote:
> > On Wed, 2022-11-09 at 13:17 +0200, Mike Rapoport wrote:
> > > On Tue, Nov 08, 2022 at 04:51:12PM +0000, Edgecombe, Rick P wrote:
> >
> > > How the caching of large pages in vmalloc can be made useful for use
> > > cases like secretmem and PKS?
> >
> > This part is easy I think. If we had an unmapped page allocator it
> > could just feed this.
>
> The unmapped page allocator could be used by anything that needs
> non-default permissions in the direct map and knows how to map the pages
> elsewhere. E.g it would have been a oneliner to switch x86::module_alloc()
> to use unmapped allocations. But ...
>
> > Do you have any idea when you might pick up that stuff again?
>
> ... unfortunately I don't see it happening anytime soon.
>
> > To answer my own question, I think a good first step would be to make
> > the interface also work for non-text_poke() so it could really be cross
> > arch, then use it for everything except modules. The benefit to the
> > other arch's at that point is centralized handling of loading text.
>
> 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.

If there is a better API, it shouldn't be too hard to do the migration. See the
example in 3/5 of the set, where we move x86 BPF jit AND BPF dispatcher
from bpf_prog_pack to execmem_alloc():

  5 files changed, 21 insertions(+), 201 deletions(-)

It is not a one liner, but it is definitely very easy.

>
> 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?

Thanks,
Song