From: Jiri Olsa <olsajiri@gmail.com>
To: Mike Rapoport <rppt@kernel.org>
Cc: Jiri Olsa <olsajiri@gmail.com>,
Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@alien8.de>,
Daniel Borkmann <daniel@iogearbox.net>,
Dave Hansen <dave.hansen@linux.intel.com>,
Eduard Zingerman <eddyz87@gmail.com>,
Ingo Molnar <mingo@redhat.com>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>,
Peter Zijlstra <peterz@infradead.org>, Song Liu <song@kernel.org>,
Thomas Gleixner <tglx@kernel.org>,
Emil Tsalapatis <emil@etsalapatis.com>,
John Fastabend <john.fastabend@gmail.com>,
Martin KaFai Lau <martin.lau@linux.dev>,
"H. Peter Anvin" <hpa@zytor.com>,
Yonghong Song <yonghong.song@linux.dev>,
bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
x86@kernel.org, Leon Hwang <leon.hwang@linux.dev>
Subject: Re: [PATCH bpf-next v3 4/5] bpf, x86: make sure allocation in arch_bpf_trampoline_size() is writable
Date: Sun, 16 Aug 2026 22:13:02 +0200 [thread overview]
Message-ID: <aoIZztIXgtbs7iaW@krava> (raw)
In-Reply-To: <aoF7f3lH_rz7mxSR@kernel.org>
On Sun, Aug 16, 2026 at 11:57:35AM +0300, Mike Rapoport wrote:
SNIP
> From 14dff78529a9204408a5c14036954df5f2f76431 Mon Sep 17 00:00:00 2001
> From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
> Date: Sun, 16 Aug 2026 11:27:32 +0300
> Subject: [PATCH] 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")
> Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
looks good, thanks
serial_test_tracing_multi_bench_attach: found 55077 functions
serial_test_tracing_multi_bench_attach: attached in 1.470s
serial_test_tracing_multi_bench_attach: detached in 0.249s
Tested-by: Jiri Olsa <jolsa@kernel.org>
jirka
> ---
> arch/x86/net/bpf_jit_comp.c | 8 +++++---
> include/linux/filter.h | 1 -
> kernel/bpf/core.c | 5 -----
> 3 files changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> index b2feec81e231..7d064d3e2788 100644
> --- a/arch/x86/net/bpf_jit_comp.c
> +++ b/arch/x86/net/bpf_jit_comp.c
> @@ -13,6 +13,7 @@
> #include <linux/bpf_verifier.h>
> #include <linux/memory.h>
> #include <linux/sort.h>
> +#include <linux/execmem.h>
> #include <asm/extable.h>
> #include <asm/ftrace.h>
> #include <asm/set_memory.h>
> @@ -3706,15 +3707,16 @@ int arch_bpf_trampoline_size(const struct btf_func_model *m, u32 flags,
> *
> * We cannot use kvmalloc here, because we need image to be in
> * module memory range.
> - * Since it must be writable use bpf_jit_alloc_exec_rw().
> + * Since it must be writable use execmem_alloc(EXECMEM_MODULE_DATA)
> + * that returns writable memory in the module address space.
> */
> - image = bpf_jit_alloc_exec_rw(PAGE_SIZE);
> + image = execmem_alloc(EXECMEM_MODULE_DATA, PAGE_SIZE);
> if (!image)
> return -ENOMEM;
>
> ret = __arch_prepare_bpf_trampoline(&im, image, image + PAGE_SIZE, image,
> m, flags, tnodes, func_addr);
> - bpf_jit_free_exec(image);
> + execmem_free(image);
> return ret;
> }
>
> diff --git a/include/linux/filter.h b/include/linux/filter.h
> index 32d5297c557e..14acb2455746 100644
> --- a/include/linux/filter.h
> +++ b/include/linux/filter.h
> @@ -1333,7 +1333,6 @@ bpf_jit_binary_alloc(unsigned int proglen, u8 **image_ptr,
> void bpf_jit_binary_free(struct bpf_binary_header *hdr);
> u64 bpf_jit_alloc_exec_limit(void);
> void *bpf_jit_alloc_exec(unsigned long size);
> -void *bpf_jit_alloc_exec_rw(unsigned long size);
> void bpf_jit_free_exec(void *addr);
> void bpf_jit_free(struct bpf_prog *fp);
> struct bpf_binary_header *
> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> index e2076667b245..1b89c18cf246 100644
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
> @@ -1128,11 +1128,6 @@ void *bpf_jit_alloc_exec(unsigned long size)
> return execmem_alloc(EXECMEM_BPF, size);
> }
>
> -void *bpf_jit_alloc_exec_rw(unsigned long size)
> -{
> - return execmem_alloc_rw(EXECMEM_BPF, size);
> -}
> -
> void bpf_jit_free_exec(void *addr)
> {
> execmem_free(addr);
> --
> 2.53.0
>
>
> > thanks,
> > jirka
>
> --
> Sincerely yours,
> Mike.
next prev parent reply other threads:[~2026-08-16 20:13 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-16 7:51 [PATCH bpf-next v3 0/5] bpf, x86: enable EXECMEM_ROX_CACHE for BPF allocations Mike Rapoport (Microsoft)
2026-07-16 7:51 ` [PATCH bpf-next v3 1/5] bpf: dispatcher: allocate bpf_dispatcher->rw_image with vzalloc() Mike Rapoport (Microsoft)
2026-07-16 8:52 ` bot+bpf-ci
2026-07-16 9:27 ` Mike Rapoport
2026-07-16 9:49 ` Kumar Kartikeya Dwivedi
2026-07-16 7:51 ` [PATCH bpf-next v3 2/5] bpf: drop __weak from bpf_jit_alloc_exec() and bpf_jit_free_exec() Mike Rapoport (Microsoft)
2026-07-16 7:51 ` [PATCH bpf-next v3 3/5] bpf: alloc_prog_pack(): skip ROX management for already ROX memory Mike Rapoport (Microsoft)
2026-07-16 7:51 ` [PATCH bpf-next v3 4/5] bpf, x86: make sure allocation in arch_bpf_trampoline_size() is writable Mike Rapoport (Microsoft)
2026-08-14 14:53 ` Jiri Olsa
2026-08-16 8:57 ` Mike Rapoport
2026-08-16 20:13 ` Jiri Olsa [this message]
2026-08-16 20:44 ` Jiri Olsa
2026-07-16 7:51 ` [PATCH bpf-next v3 5/5] x86/bpf: enable EXECMEM_ROX_CACHE for BPF allocations Mike Rapoport (Microsoft)
2026-07-17 0:00 ` [PATCH bpf-next v3 0/5] bpf, x86: " Song Liu
2026-07-17 6:41 ` Mike Rapoport
2026-07-17 7:27 ` Song Liu
2026-07-17 9:29 ` Mike Rapoport
2026-07-17 17:50 ` Song Liu
2026-07-19 9:23 ` Mike Rapoport
2026-07-21 17:59 ` Song Liu
2026-07-22 8:05 ` Mike Rapoport
2026-07-22 15:04 ` Song Liu
2026-07-27 8:35 ` Mike Rapoport
2026-07-22 15:40 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aoIZztIXgtbs7iaW@krava \
--to=olsajiri@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bp@alien8.de \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=dave.hansen@linux.intel.com \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=hpa@zytor.com \
--cc=john.fastabend@gmail.com \
--cc=leon.hwang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rppt@kernel.org \
--cc=song@kernel.org \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.