All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
To: "Jiayuan Chen" <jiayuan.chen@linux.dev>, <bpf@vger.kernel.org>
Cc: "Emil Tsalapatis" <emil@etsalapatis.com>,
	"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: Re: [PATCH bpf-next v7 1/4] bpf: Add a sleepable page allocator for map memory
Date: Thu, 17 Sep 2026 02:17:53 +0000	[thread overview]
Message-ID: <DLH8BLA0ZCFY.3U2Q1BS1DBTYU@gmail.com> (raw)
In-Reply-To: <20260917015618.7488-2-jiayuan.chen@linux.dev>

On Thu, Sep 17, 2026 at 09:55 AM Jiayuan Chen <jiayuan.chen@linux.dev> wrote:
> 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);

[...]

> 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

[...]

> @@ -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);
> +}

Don't see the point in #define BPF_PAGE_GFP

Just call
  alloc_pages_node(map->numa_node, GFP_KERNEL | __GFP_ZERO |
		   __GFP_ACCOUNT | __GFP_NOWARN 
| __GFP_RETRY_MAYFAIL, 0);

with a one line comment why RETRY_MAYFAIL, 
drop this patch and fold mayfail+comment into patch 2.

pw-bot: cr

  reply	other threads:[~2026-09-17  2:17 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 ` [PATCH bpf-next v7 1/4] bpf: Add a sleepable page allocator for map memory Jiayuan Chen
2026-09-17  2:17   ` Alexei Starovoitov [this message]
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=DLH8BLA0ZCFY.3U2Q1BS1DBTYU@gmail.com \
    --to=alexei.starovoitov@gmail.com \
    --cc=andrii@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=jiayuan.chen@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.