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

>     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 <[email protected]>
>     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")

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


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/32142507111