BPF List
 help / color / mirror / Atom feed
From: Puranjay Mohan <puranjay@kernel.org>
To: bpf@vger.kernel.org
Cc: Puranjay Mohan <puranjay@kernel.org>,
	"Alexei Starovoitov" <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Andrii Nakryiko" <andrii@kernel.org>,
	"Martin KaFai Lau" <martin.lau@linux.dev>,
	"Eduard Zingerman" <eddyz87@gmail.com>,
	"Kumar Kartikeya Dwivedi" <memxor@gmail.com>,
	"Song Liu" <song@kernel.org>,
	"Yonghong Song" <yonghong.song@linux.dev>,
	Mykyta Yatsenko <mykyta.yatsenko5@gmail.com>
Subject: [PATCH bpf 2/2] bpf: Invalidate freed prog pack memory without holding pack_mutex
Date: Tue,  3 Nov 2026 06:28:54 -0800	[thread overview]
Message-ID: <20261103142856.463063-3-puranjay@kernel.org> (raw)
In-Reply-To: <20261103142856.463063-1-puranjay@kernel.org>

bpf_prog_pack_free() calls bpf_arch_text_invalidate() with pack_mutex
held. On arm64 it interrupts all other CPUs and waits for them:

  bpf_prog_free_deferred
    bpf_prog_free_images
      bpf_jit_free
        bpf_jit_binary_pack_free
          bpf_prog_pack_free
            bpf_arch_text_invalidate
              aarch64_insn_set
                __text_poke
                  flush_icache_range
                    kick_all_cpus_sync

When many progs are freed at once, every prog load waits in
bpf_prog_pack_alloc() for all of these broadcasts. On arm64 hosts with
many CPUs this showed up as hung task reports with sk_attach_filter()
blocked on pack_mutex for minutes.

pack_mutex protects pack_list, the bitmaps and arch_flush_needed, not
the text. Until bitmap_clear(), the bits of the range are set, so it
cannot be allocated again and the pack cannot be freed. Invalidate it
before taking pack_mutex. A ptr that is in no pack, which only a caller
bug can pass, is now written to before the lookup warns about it.

Tested in arm64 KVM guests with 16 and 64 cpus on a 72 cpu host. cpus/2
processes attach a cBPF filter to 256 sockets and close them in a loop
for 20 sec. One more process attaches a filter every msec. Median of 5
runs.

Sockets attached and closed in 20 sec, in millions (higher is better):

             before  after
  16 cpus      1.22   3.79
  64 cpus      0.42   3.38

setsockopt(SO_ATTACH_FILTER) of the process that attaches every msec,
in msec (lower is better):

                16 cpus          64 cpus
             before  after    before  after
  avg          1.32   0.27      7.21   0.56
  p99          5.39   5.52      79.7   9.89
  max           447    159      1598    253

Fixes: 1dad391daef1 ("bpf, arm64: use bpf_prog_pack for memory management")
Suggested-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
---
 kernel/bpf/core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 4dac33a4208aa..51f1b128f0d63 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -1073,6 +1073,9 @@ void bpf_prog_pack_free(void *ptr, u32 size)
 		return;
 	}
 
+	WARN_ONCE(bpf_arch_text_invalidate(ptr, size),
+		  "bpf_prog_pack bug: missing bpf_arch_text_invalidate?\n");
+
 	mutex_lock(&pack_mutex);
 	list_for_each_entry(tmp, &pack_list, list) {
 		if (ptr >= tmp->ptr && (tmp->ptr + BPF_PROG_PACK_SIZE) > ptr) {
@@ -1087,9 +1090,6 @@ void bpf_prog_pack_free(void *ptr, u32 size)
 	nbits = BPF_PROG_SIZE_TO_NBITS(size);
 	pos = ((unsigned long)ptr - (unsigned long)pack->ptr) >> BPF_PROG_CHUNK_SHIFT;
 
-	WARN_ONCE(bpf_arch_text_invalidate(ptr, size),
-		  "bpf_prog_pack bug: missing bpf_arch_text_invalidate?\n");
-
 	bitmap_clear(pack->bitmap, pos, nbits);
 
 	if (static_branch_unlikely(&bpf_pred_flush_enabled))
-- 
2.53.0-Meta


      parent reply	other threads:[~2026-11-03 14:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-03 14:28 [PATCH bpf 0/2] bpf: Shorten pack_mutex critical sections Puranjay Mohan
2026-11-03 14:28 ` [PATCH bpf 1/2] bpf: Don't allocate and free prog pack memory with pack_mutex held Puranjay Mohan
2026-11-03 15:20   ` bot+bpf-ci
2026-11-03 16:47   ` Alexei Starovoitov
2026-11-05 18:27     ` Emil Tsalapatis
2026-11-03 14:28 ` Puranjay Mohan [this message]

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=20261103142856.463063-3-puranjay@kernel.org \
    --to=puranjay@kernel.org \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=martin.lau@linux.dev \
    --cc=memxor@gmail.com \
    --cc=mykyta.yatsenko5@gmail.com \
    --cc=song@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox