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

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

On Tue, 2022-11-08 at 13:27 +0200, Mike Rapoport wrote:
> > Based on our experiments [5], we measured 0.5% performance
> > improvement
> > from bpf_prog_pack. This patchset further boosts the improvement to
> > 0.7%.
> > The difference is because bpf_prog_pack uses 512x 4kB pages instead
> > of
> > 1x 2MB page, bpf_prog_pack as-is doesn't resolve #2 above.
> > 
> > This patchset replaces bpf_prog_pack with a better API and makes it
> > available for other dynamic kernel text, such as modules, ftrace,
> > kprobe.
> 
>  
> The proposed execmem_alloc() looks to me very much tailored for x86
> to be
> used as a replacement for module_alloc(). Some architectures have
> module_alloc() that is quite different from the default or x86
> version, so
> I'd expect at least some explanation how modules etc can use execmem_
> APIs
> without breaking !x86 architectures.

I think this is fair, but I think we should ask ask ourselves - how
much should we do in one step?

For non-text_poke() architectures, the way you can make it work is have
the API look like:
execmem_alloc()  <- Does the allocation, but necessarily usable yet
execmem_write()  <- Loads the mapping, doesn't work after finish()
execmem_finish() <- Makes the mapping live (loaded, executable, ready)

So for text_poke():
execmem_alloc()  <- reserves the mapping
execmem_write()  <- text_pokes() to the mapping
execmem_finish() <- does nothing

And non-text_poke():
execmem_alloc()  <- Allocates a regular RW vmalloc allocation
execmem_write()  <- Writes normally to it
execmem_finish() <- does set_memory_ro()/set_memory_x() on it

Non-text_poke() only gets the benefits of centralized logic, but the
interface works for both. This is pretty much what the perm_alloc() RFC
did to make it work with other arch's and modules. But to fit with the
existing modules code (which is actually spread all over) and also
handle RO sections, it also needed some additional bells and whistles.

So the question I'm trying to ask is, how much should we target for the
next step? I first thought that this functionality was so intertwined,
it would be too hard to do iteratively. So if we want to try
iteratively, I'm ok if it doesn't solve everything.