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

[Mike Rapoport]

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@xxxxxxxxxx> 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.

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.

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 :)

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?
 
> Thanks,
> Song

-- 
Sincerely yours,
Mike.