Re: [PATCH bpf-next v3 0/5] bpf, x86: enable EXECMEM_ROX_CACHE for BPF allocations

[Song Liu <song@kernel.org>]

On Thu, Jul 16, 2026 at 11:41 PM Mike Rapoport <rppt@kernel.org> wrote:
>
> On Thu, Jul 16, 2026 at 05:00:11PM -0700, Song Liu wrote:
> > On Thu, Jul 16, 2026 at 12:51 AM Mike Rapoport (Microsoft)
> > <rppt@kernel.org> wrote:
> > >
> > > Hi,
> > >
> > > BPF allocations of executable memory on x86 are essentially read-only. Most
> > > paths that call bpf_jit_alloc_exec() immediately make it ROX with
> > > set_memory_rox().
> > >
> > > The code generation, at least on x86, uses separately allocated writable
> > > buffers and then updates the actual text memory with text_poke().
> > >
> > > These patches do several small adjustments to how BPF allocates executable
> > > memory and enable EXECMEM_ROX_CACHE for BPF allocations on x86.
> >
> > After this set, we are still using bpf_prog_pack_alloc() from x86 code. I think
> > the goal is to eventually remove bpf_prog_pack_alloc(). What's our plan for
> > the next steps (toward removing bpf_prog_pack_alloc)?
>
> "It works, don't touch"? ;-)
>
> We can add another layer for sub-page allocations to execmem.

Sub-page allocation is not a hard requirement here. Using 4kB for
each small BPF program isn't too bad. We added bpf_prog_pack to
avoid fragmentation of direct map page table entry (caused by W^X
requirement). If execmem allocator reserves large enough ROX
memory (with PMD page table entries) and reuses them properly,
we shouldn't see page table fragmentation getting worse over time.
Then, we can use 4kB granularity allocation for BPF programs. (I am
not sure about 64kB pages..).

>
> Since BPF is the only user the easiest would be just to move prog_pack
> logic from BPF to execmem and call it a day.

If we move to bigger page sizes, say 64kB, there will be other
users that would benefit from sub page allocation, right?

> Another option is to add a slab-like layer for sub-page allocations to
> execmem. This is more complex but it would allow to get rid of the rigid
> BPF_PROG_CHUNK_SIZE.
>
> Maybe it would be also possible to teach SLUB to use execmem_alloc()
> instead of alloc_pages() but that's surely the most far fetched one :)

I was thinking some rb-tree algorithm might be useful here,
something similar to vmap.

> And since we are talking about bpf_prog_pack_alloc(), why
> BPF_PROG_PACK_SIZE accounts for num_possible_nodes():
>
> #define BPF_PROG_PACK_SIZE (SZ_2M * num_possible_nodes())
>
> Is it an elaborate choice or it was picked to work around older
> vmalloc_huge() limitations?

It is a bit complicated. The goal is to get PMDs for prog_pack.
We can adjust this if vmalloc_huge() changes after that.

Thanks,
Song