Re: [PATCH] x86/bpf: make arch_bpf_trampoline_size allocate from EXECMEM_MODULE_DATA

From: Mike Rapoport

Date: Wed Aug 19 2026 - 02:43:43 EST


On Tue, Aug 18, 2026 at 02:07:23PM +0000, bot+bpf-ci@xxxxxxxxxx wrote:
> > x86/bpf: make arch_bpf_trampoline_size allocate from EXECMEM_MODULE_DATA
> >
> > Jiri Olsa reports slowdown of tracing_multi benchmark that allocates huge
> > number of trampolines [1].
> >
> > The slowdown caused by extra protection changes in execmem_alloc_rw() and
> > execmem_free().
> >
> > With ROX caches enabled, all execmem allocations except EXECMEM_MODULE_DATA
> > are ROX after the allocation. execmem_alloc_rw() temporarily sets them to
> > W+NX and execmem_free() resets them back to ROX.
> >
> > The only user of bpf_jit_alloc_exec_rw() is x86::arch_bpf_trampoline_size()
> > that only needs a temporary writable buffer in the modules address space.
> >
> > On x86 executable memory and module data are constrained to the same
> > address range, so x86::arch_bpf_trampoline_size() can directly use
> > execmem_alloc(EXECMEM_MODULE_DATA)
> >
> > Replace the call to bpf_jit_alloc_exec_rw() with a call to
> > execmem_alloc(EXECMEM_MODULE_DATA) in x86::arch_bpf_trampoline_size() and
> > drop bpf_jit_alloc_exec_rw() helper.
> >
> > Reported-by: Jiri Olsa <olsajiri@xxxxxxxxx>
> > Link: https://lore.kernel.org/all/an8r7EODLIL-bZM3@krava
> > Fixes: f0334294a428 ("bpf, x86: make sure allocation in arch_bpf_trampoline_size() is writable")
> ^^^^^^^^^^^^
>
> The Fixes tag references commit f0334294a428, which does not exist in
> this repository. Should this be:
>
> Fixes: 5bf02dbf39fa ("bpf, x86: Make sure allocation in arch_bpf_trampoline_size() is writable")

Argh, checked the log on a wrong branch.

Can you folks fix it up when applying or you'd need v3?

> That commit introduced bpf_jit_alloc_exec_rw() and the performance issue
> being addressed here.

--
Sincerely yours,
Mike.