From: Jiayuan Chen <jiayuan.chen@linux.dev>
To: bpf@vger.kernel.org
Cc: Jiayuan Chen <jiayuan.chen@linux.dev>,
Emil Tsalapatis <emil@etsalapatis.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>,
Martin KaFai Lau <martin.lau@linux.dev>,
Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
Jiri Olsa <jolsa@kernel.org>,
Ihor Solodrai <ihor.solodrai@linux.dev>,
John Fastabend <john.fastabend@gmail.com>,
Shuah Khan <shuah@kernel.org>,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: [PATCH bpf-next v7 1/4] bpf: Add a sleepable page allocator for map memory
Date: Thu, 17 Sep 2026 09:55:06 +0800 [thread overview]
Message-ID: <20260917015618.7488-2-jiayuan.chen@linux.dev> (raw)
In-Reply-To: <20260917015618.7488-1-jiayuan.chen@linux.dev>
bpf_map_alloc_pages() can use a non-blocking allocator that never
reclaims. Add bpf_map_alloc_page_sleepable() which always uses the
blocking allocator, so the allocation can reclaim. It uses
__GFP_RETRY_MAYFAIL so it never invokes the OOM killer: the page is
charged to the map's memcg, which need not be the caller's, so an OOM
there could kill unrelated tasks in the map's cgroup while a foreign
caller could never be its victim. The caller is responsible for a
context where blocking is safe; see the function comment.
Like the other bpf map allocators it places the page on the map's
numa_node and does not follow the faulting task's NUMA mempolicy; arena
memory is shared, so the map's node is the right placement policy. The
next patch uses it from the arena page fault handler.
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
---
To sashiko:
- The alloc_pages_nolock() fallback still zeroes: it forces __GFP_ZERO
internally and only accepts __GFP_ACCOUNT.
- __GFP_ZERO is unchanged from the existing __bpf_alloc_page(), and no
arena-capable arch has D-cache aliasing, so there is no dcache concern.
---
include/linux/bpf.h | 1 +
kernel/bpf/syscall.c | 28 ++++++++++++++++++++++++----
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index e80963971f680..345fe4c2e6422 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -2786,6 +2786,7 @@ struct bpf_prog *bpf_prog_get_curr_or_next(u32 *id);
int bpf_map_alloc_pages(const struct bpf_map *map, int nid,
unsigned long nr_pages, struct page **page_array);
+struct page *bpf_map_alloc_page_sleepable(const struct bpf_map *map);
#ifdef CONFIG_MEMCG
void bpf_map_memcg_enter(const struct bpf_map *map, struct mem_cgroup **old_memcg,
struct mem_cgroup **new_memcg);
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index c7bc9ba9b331f..abd0f67c68d97 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -602,15 +602,14 @@ static bool can_alloc_pages(void)
!IS_ENABLED(CONFIG_PREEMPT_RT);
}
+#define BPF_PAGE_GFP (GFP_KERNEL | __GFP_ZERO | __GFP_ACCOUNT | __GFP_NOWARN)
+
static struct page *__bpf_alloc_page(int nid)
{
if (!can_alloc_pages())
return alloc_pages_nolock(__GFP_ACCOUNT, nid, 0);
- return alloc_pages_node(nid,
- GFP_KERNEL | __GFP_ZERO | __GFP_ACCOUNT
- | __GFP_NOWARN,
- 0);
+ return alloc_pages_node(nid, BPF_PAGE_GFP, 0);
}
int bpf_map_alloc_pages(const struct bpf_map *map, int nid,
@@ -636,6 +635,27 @@ int bpf_map_alloc_pages(const struct bpf_map *map, int nid,
return ret;
}
+/*
+ * Allocate a page for map memory with the blocking allocator so it can
+ * reclaim. __GFP_RETRY_MAYFAIL keeps it from invoking the OOM killer: the
+ * page is charged to the map's memcg, which need not be the caller's, so
+ * an OOM there could kill unrelated tasks in the map's cgroup while a
+ * foreign caller could never be its victim.
+ *
+ * bpf_map_alloc_pages() serves arbitrary BPF program context and stays
+ * reentrancy-safe by falling back to the non-blocking allocator. This
+ * helper always blocks, so a sleepable context alone is not enough: the
+ * caller must guarantee it is not already inside the page allocator or
+ * reclaim, where blocking here would reenter mm and deadlock. The only
+ * user is arena_vm_fault(), a userspace page fault in task context.
+ */
+struct page *bpf_map_alloc_page_sleepable(const struct bpf_map *map)
+{
+ might_sleep();
+ return alloc_pages_node(map->numa_node,
+ BPF_PAGE_GFP | __GFP_RETRY_MAYFAIL, 0);
+}
+
static int btf_field_cmp(const void *a, const void *b)
{
const struct btf_field *f1 = a, *f2 = b;
--
2.43.0
next prev parent reply other threads:[~2026-09-17 1:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-17 1:55 [PATCH bpf-next v7 0/4] bpf: arena: handle memory.max on fault-in with reclaim/OOM Jiayuan Chen
2026-09-17 1:55 ` Jiayuan Chen [this message]
2026-09-17 2:17 ` [PATCH bpf-next v7 1/4] bpf: Add a sleepable page allocator for map memory Alexei Starovoitov
2026-09-17 1:55 ` [PATCH bpf-next v7 2/4] bpf: arena: allocate the fault-in page outside the lock Jiayuan Chen
2026-09-17 1:55 ` [PATCH bpf-next v7 3/4] selftests/bpf: Add read_cgroup_file() to cgroup_helpers Jiayuan Chen
2026-09-17 1:55 ` [PATCH bpf-next v7 4/4] selftests/bpf: Add a test for arena fault-in under memory.max Jiayuan Chen
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=20260917015618.7488-2-jiayuan.chen@linux.dev \
--to=jiayuan.chen@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=ihor.solodrai@linux.dev \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=shuah@kernel.org \
--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 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.