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

[Mike Rapoport <rppt@kernel.org>]

On Tue, Aug 18, 2026 at 02:07:23PM +0000, bot+bpf-ci@kernel.org 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@gmail.com>
> >     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.