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.

---
v3 changes:
* replace vmalloc() with vzalloc() in bpf_dispatcher_change_prog()
* rebase on the current bpf-next

v2: https://patch.msgid.link/20260711-execmem-x86-rox-bpf-v0-v2-0-bfd956d35119@kernel.org
* rebase on the current bpf-next

v1: https://patch.msgid.link/20260626-execmem-x86-rox-bpf-v0-v1-0-45a0b0ed4fe9@kernel.org

---

---
Mike Rapoport (Microsoft) (5):
      bpf: dispatcher: allocate bpf_dispatcher->rw_image with vzalloc()
      bpf: drop __weak from bpf_jit_alloc_exec() and bpf_jit_free_exec()
      bpf: alloc_prog_pack(): skip ROX management for already ROX memory
      bpf, x86: make sure allocation in arch_bpf_trampoline_size() is writable
      x86/bpf: enable EXECMEM_ROX_CACHE for BPF allocations

 arch/x86/mm/init.c          |  4 ++--
 arch/x86/net/bpf_jit_comp.c |  5 ++---
 include/linux/filter.h      |  1 +
 kernel/bpf/core.c           | 30 +++++++++++++++++++++---------
 kernel/bpf/dispatcher.c     |  5 ++++-
 5 files changed, 30 insertions(+), 15 deletions(-)
---
base-commit: d1f4b56417a3dc1a0600f960b14f46bd25eda89d
change-id: 20260626-execmem-x86-rox-bpf-v0-b4241ade80df

--
Sincerely yours,
Mike.

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

Thanks,
Song

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.

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.

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

On Fri, Jul 17, 2026 at 12:27:03AM -0700, Song Liu wrote:
> 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..).

execmem uses PMD_SIZE pages for ROX cache. Since right now it's only
supported on x86, the issue with oversized large page with 64k base pages
didn't come up yet.
 
> > 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?

Maybe modules could, don't know TBH.
There is another caveat with sub-page allocations: they must preserve ROX
and no subsystem except BPF can deal with ROX-only allocations and writable
copies.
 
> > 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.

Could be that or maple_tree especially considering there's an active
discussion about converting vmalloc to maple_tree as well:

https://lore.kernel.org/linux-mm/20260613-vmalloc_maple-v1-0-0aa740bb944b@oss.qualcomm.com/

But the choice of allocation algorithm is anyway secondary to the decision
whether execmem should have the sub-page allocator.

If you say that a page per BPF program is fine, than maybe we can just rip
off bpf_prog_pack_alloc().
If BPF still needs to maintain the ability to allocate in smaller chunks,
then maybe the best way is to keep bpf_prog_pack_alloc() as is because I
don't foresee other users for small page allocations any time soon.
 
> > 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.

Since commit c82be0be9576 ("mm: vmalloc: don't account for number of nodes
for HUGE_VMAP allocations") vmalloc_huge() is fine with PMD_SIZE regardless
of number of nodes.

With 64k pages it's still a lot though.
 
> Thanks,
> Song

-- 
Sincerely yours,
Mike.

On Fri, Jul 17, 2026 at 2:29 AM Mike Rapoport <rppt@kernel.org> wrote:
[...]
> > >
> > > "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..).
>
> execmem uses PMD_SIZE pages for ROX cache. Since right now it's only
> supported on x86, the issue with oversized large page with 64k base pages
> didn't come up yet.

With 64kB page size, PMD_SIZE is probably too big for 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.
> >
> > If we move to bigger page sizes, say 64kB, there will be other
> > users that would benefit from sub page allocation, right?
>
> Maybe modules could, don't know TBH.
> There is another caveat with sub-page allocations: they must preserve ROX
> and no subsystem except BPF can deal with ROX-only allocations and writable
> copies.

I think ftrace and kprobe could be good users?

> > > 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.
>
> Could be that or maple_tree especially considering there's an active
> discussion about converting vmalloc to maple_tree as well:
>
> https://lore.kernel.org/linux-mm/20260613-vmalloc_maple-v1-0-0aa740bb944b@oss.qualcomm.com/
>
> But the choice of allocation algorithm is anyway secondary to the decision
> whether execmem should have the sub-page allocator.
>
> If you say that a page per BPF program is fine, than maybe we can just rip
> off bpf_prog_pack_alloc().
> If BPF still needs to maintain the ability to allocate in smaller chunks,
> then maybe the best way is to keep bpf_prog_pack_alloc() as is because I
> don't foresee other users for small page allocations any time soon.
>
> > > 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.
>
> Since commit c82be0be9576 ("mm: vmalloc: don't account for number of nodes
> for HUGE_VMAP allocations") vmalloc_huge() is fine with PMD_SIZE regardless
> of number of nodes.

Before execmem can handle sub page allocations, how about we
send allocations that are bigger than page size directly to execmem,
and let bpf_prog_pack handle sub page allocations. Then,
BPF_PROG_PACK_SIZE will be PAGE_SIZE. This should be a net
win for x86_64. Other archs will be the same. WDYT?

Thanks,
Song

On Fri, Jul 17, 2026 at 10:50:09AM -0700, Song Liu wrote:
> On Fri, Jul 17, 2026 at 2:29 AM Mike Rapoport <rppt@kernel.org> wrote:
> [...]
> > > >
> > > > "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..).
> >
> > execmem uses PMD_SIZE pages for ROX cache. Since right now it's only
> > supported on x86, the issue with oversized large page with 64k base pages
> > didn't come up yet.
> 
> With 64kB page size, PMD_SIZE is probably too big for execmem.

Yeah, I think so. But maybe on arm64 with 64kB pages we could use CONT_PTE.
 
> > > > 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?
> >
> > Maybe modules could, don't know TBH.
> > There is another caveat with sub-page allocations: they must preserve ROX
> > and no subsystem except BPF can deal with ROX-only allocations and writable
> > copies.
> 
> I think ftrace and kprobe could be good users?

Don't know about ftrace, but kprobes essentially has page-sized caches and
uses them internally.
 
> > > > 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.
> >
> > Could be that or maple_tree especially considering there's an active
> > discussion about converting vmalloc to maple_tree as well:
> >
> > https://lore.kernel.org/linux-mm/20260613-vmalloc_maple-v1-0-0aa740bb944b@oss.qualcomm.com/
> >
> > But the choice of allocation algorithm is anyway secondary to the decision
> > whether execmem should have the sub-page allocator.
> >
> > If you say that a page per BPF program is fine, than maybe we can just rip
> > off bpf_prog_pack_alloc().
> > If BPF still needs to maintain the ability to allocate in smaller chunks,
> > then maybe the best way is to keep bpf_prog_pack_alloc() as is because I
> > don't foresee other users for small page allocations any time soon.
> >
> > > > 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.
> >
> > Since commit c82be0be9576 ("mm: vmalloc: don't account for number of nodes
> > for HUGE_VMAP allocations") vmalloc_huge() is fine with PMD_SIZE regardless
> > of number of nodes.
> 
> Before execmem can handle sub page allocations, how about we
> send allocations that are bigger than page size directly to execmem,
> and let bpf_prog_pack handle sub page allocations. Then,
> BPF_PROG_PACK_SIZE will be PAGE_SIZE. This should be a net
> win for x86_64. Other archs will be the same. WDYT?

Makes perfect sense to me for x86.

On architectures that support large mappings in the direct map and do not
support EXECMEM_CACHE_ROX this will increase direct map fragmentation.
 
> Thanks,
> Song

-- 
Sincerely yours,
Mike.

On Sun, Jul 19, 2026 at 2:23 AM Mike Rapoport <rppt@kernel.org> wrote:
>
> On Fri, Jul 17, 2026 at 10:50:09AM -0700, Song Liu wrote:
> > On Fri, Jul 17, 2026 at 2:29 AM Mike Rapoport <rppt@kernel.org> wrote:
> > [...]
> > > > >
> > > > > "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..).
> > >
> > > execmem uses PMD_SIZE pages for ROX cache. Since right now it's only
> > > supported on x86, the issue with oversized large page with 64k base pages
> > > didn't come up yet.
> >
> > With 64kB page size, PMD_SIZE is probably too big for execmem.
>
> Yeah, I think so. But maybe on arm64 with 64kB pages we could use CONT_PTE.
>
> > > > > 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?
> > >
> > > Maybe modules could, don't know TBH.
> > > There is another caveat with sub-page allocations: they must preserve ROX
> > > and no subsystem except BPF can deal with ROX-only allocations and writable
> > > copies.
> >
> > I think ftrace and kprobe could be good users?
>
> Don't know about ftrace, but kprobes essentially has page-sized caches and
> uses them internally.
>
> > > > > 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.
> > >
> > > Could be that or maple_tree especially considering there's an active
> > > discussion about converting vmalloc to maple_tree as well:
> > >
> > > https://lore.kernel.org/linux-mm/20260613-vmalloc_maple-v1-0-0aa740bb944b@oss.qualcomm.com/
> > >
> > > But the choice of allocation algorithm is anyway secondary to the decision
> > > whether execmem should have the sub-page allocator.
> > >
> > > If you say that a page per BPF program is fine, than maybe we can just rip
> > > off bpf_prog_pack_alloc().
> > > If BPF still needs to maintain the ability to allocate in smaller chunks,
> > > then maybe the best way is to keep bpf_prog_pack_alloc() as is because I
> > > don't foresee other users for small page allocations any time soon.
> > >
> > > > > 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.
> > >
> > > Since commit c82be0be9576 ("mm: vmalloc: don't account for number of nodes
> > > for HUGE_VMAP allocations") vmalloc_huge() is fine with PMD_SIZE regardless
> > > of number of nodes.
> >
> > Before execmem can handle sub page allocations, how about we
> > send allocations that are bigger than page size directly to execmem,
> > and let bpf_prog_pack handle sub page allocations. Then,
> > BPF_PROG_PACK_SIZE will be PAGE_SIZE. This should be a net
> > win for x86_64. Other archs will be the same. WDYT?
>
> Makes perfect sense to me for x86.

Can we include this change to this patch set? This will make this
change a meaningful step towards migrating to EXECMEM.

> On architectures that support large mappings in the direct map and do not
> support EXECMEM_CACHE_ROX this will increase direct map fragmentation.

Architectures that support bpf_prog_pack can benefit from
EXECMEM_CACHE_ROX. What does it take to also enable
EXECMEM_CACHE_ROX for them?

Thanks,
Song

On Tue, Jul 21, 2026 at 10:59:06AM -0700, Song Liu wrote:
> On Sun, Jul 19, 2026 at 2:23 AM Mike Rapoport <rppt@kernel.org> wrote:
> > > >
> > > > Since commit c82be0be9576 ("mm: vmalloc: don't account for number of nodes
> > > > for HUGE_VMAP allocations") vmalloc_huge() is fine with PMD_SIZE regardless
> > > > of number of nodes.
> > >
> > > Before execmem can handle sub page allocations, how about we
> > > send allocations that are bigger than page size directly to execmem,
> > > and let bpf_prog_pack handle sub page allocations. Then,
> > > BPF_PROG_PACK_SIZE will be PAGE_SIZE. This should be a net
> > > win for x86_64. Other archs will be the same. WDYT?
> >
> > Makes perfect sense to me for x86.
> 
> Can we include this change to this patch set? This will make this
> change a meaningful step towards migrating to EXECMEM.

I'd prefer to leave this as a separate followup. 

The decision whether to use EXECMEM_ROX_CACHE is made at runtime, which
means that BPF_PROG_PACK_SIZE should become a variable, that variable needs
initialization at some point during boot and that in turn requires a new
helper in execmem that will say if EXECMEM_CACHE_ROX is enabled.
 
> > On architectures that support large mappings in the direct map and do not
> > support EXECMEM_CACHE_ROX this will increase direct map fragmentation.
> 
> Architectures that support bpf_prog_pack can benefit from
> EXECMEM_CACHE_ROX. What does it take to also enable
> EXECMEM_CACHE_ROX for them?

For EXECMEM_ROX_CACHE to help in reducing the fragmentation and TLB
pressure an architecture should support collapsing of the split mappings at
least in vmalloc/modules space.

There is an RFC for arm64 to add support for EXECMEM_ROX_CACHE there:

https://lore.kernel.org/all/20260611130144.1385343-1-abarnas@google.com

and it looks like it'll take a couple of iterations :)

I don't how much work it would be for other architectures.
 
> Thanks,
> Song

-- 
Sincerely yours,
Mike.

On Wed, Jul 22, 2026 at 1:06 AM Mike Rapoport <rppt@kernel.org> wrote:
>
> On Tue, Jul 21, 2026 at 10:59:06AM -0700, Song Liu wrote:
> > On Sun, Jul 19, 2026 at 2:23 AM Mike Rapoport <rppt@kernel.org> wrote:
> > > > >
> > > > > Since commit c82be0be9576 ("mm: vmalloc: don't account for number of nodes
> > > > > for HUGE_VMAP allocations") vmalloc_huge() is fine with PMD_SIZE regardless
> > > > > of number of nodes.
> > > >
> > > > Before execmem can handle sub page allocations, how about we
> > > > send allocations that are bigger than page size directly to execmem,
> > > > and let bpf_prog_pack handle sub page allocations. Then,
> > > > BPF_PROG_PACK_SIZE will be PAGE_SIZE. This should be a net
> > > > win for x86_64. Other archs will be the same. WDYT?
> > >
> > > Makes perfect sense to me for x86.
> >
> > Can we include this change to this patch set? This will make this
> > change a meaningful step towards migrating to EXECMEM.
>
> I'd prefer to leave this as a separate followup.
>
> The decision whether to use EXECMEM_ROX_CACHE is made at runtime, which
> means that BPF_PROG_PACK_SIZE should become a variable, that variable needs
> initialization at some point during boot and that in turn requires a new
> helper in execmem that will say if EXECMEM_CACHE_ROX is enabled.

Hmm... deciding whether to use EXECMEM_ROX_CACHE at runtime seems
weird. Can we enable it all the time and decide how much memory it reserves
at runtime?

Given this constraint, we can probably ship this now and do the rest in a
follow up set.

For the set
Acked-by: Song Liu <song@kernel.org>

> > > On architectures that support large mappings in the direct map and do not
> > > support EXECMEM_CACHE_ROX this will increase direct map fragmentation.
> >
> > Architectures that support bpf_prog_pack can benefit from
> > EXECMEM_CACHE_ROX. What does it take to also enable
> > EXECMEM_CACHE_ROX for them?
[...]