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

[Daniel Borkmann]

On 8/19/26 8:42 AM, Mike Rapoport wrote:
> 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?

Yeap, we'll do, np.

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