From: sashiko-bot@kernel.org
To: "Andrea Righi" <arighi@nvidia.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH 1/5] bpf: Add an arena flag to retain allocated pages
Date: Sat, 10 Oct 2026 23:00:41 +0000 [thread overview]
Message-ID: <sashiko-outbox-166916@kernel.org> (raw)
In-Reply-To: <20261010224902.1232178-2-arighi@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] bpf: BPF_F_ARENA_NO_FREE breaks virtual address unreservation and kernel error rollbacks
--
commit 9eb2222524999c1d26f887b5ad559236c846afe7
Author: Andrea Righi <arighi@nvidia.com>
bpf: Add an arena flag to retain allocated pages
This commit adds BPF_F_ARENA_NO_FREE to retain arena pages until the map is
destroyed. It modifies BPF page-free operations to be no-ops in both sleepable
and non-sleepable programs when the flag is set.
> diff --git a/kernel/bpf/arena.c b/kernel/bpf/arena.c
> index 0ff707707da04..343e84139ec29 100644
> --- a/kernel/bpf/arena.c
> +++ b/kernel/bpf/arena.c
[ ... ]
> @@ -1134,7 +1135,8 @@ __bpf_kfunc void bpf_arena_free_pages(void *p__map, void *ptr__ign, u32 page_cnt
> struct bpf_map *map = p__map;
> struct bpf_arena *arena = container_of(map, struct bpf_arena, map);
>
> - if (map->map_type != BPF_MAP_TYPE_ARENA || !page_cnt || !ptr__ign)
> + if (map->map_type != BPF_MAP_TYPE_ARENA || !page_cnt || !ptr__ign ||
> + (map->map_flags & BPF_F_ARENA_NO_FREE))
> return;
[Severity: High]
Does unconditionally skipping arena_free_pages() prevent virtual address
unreservation?
When bpf_arena_free_pages() returns early, it skips range_tree_set().
This leaves the virtual addresses perpetually locked in the range tree as
"allocated", causing subsequent bpf_arena_alloc_pages() calls on that
address to fail with -EBUSY.
> arena_free_pages(arena, (long)ptr__ign, page_cnt, true);
> }
> @@ -1144,7 +1146,8 @@ void bpf_arena_free_pages_non_sleepable(void *p__map, void *ptr__ign, u32 page_c
> struct bpf_map *map = p__map;
> struct bpf_arena *arena = container_of(map, struct bpf_arena, map);
>
> - if (map->map_type != BPF_MAP_TYPE_ARENA || !page_cnt || !ptr__ign)
> + if (map->map_type != BPF_MAP_TYPE_ARENA || !page_cnt || !ptr__ign ||
> + (map->map_flags & BPF_F_ARENA_NO_FREE))
> return;
[Severity: High]
Does unconditionally skipping arena_free_pages() here break external kernel
callers that rely on this function for error rollbacks?
For example, subsystems like sched_ext use bpf_arena_free_pages_non_sleepable()
to roll back partial allocations:
kernel/sched/ext/arena.c:scx_arena_grow() {
...
ret = gen_pool_add(sch->arena_pool, ...);
if (ret) {
bpf_arena_free_pages_non_sleepable(sch->arena_map, p, page_cnt);
return ret;
}
...
}
In this kernel error path, if gen_pool_add() fails, the rollback becomes a
silent no-op.
The physical pages and virtual address range remain allocated in the arena,
but the pointer is dropped, permanently leaking capacity within the arena.
> arena_free_pages(arena, (long)ptr__ign, page_cnt, false);
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261010224902.1232178-1-arighi@nvidia.com?part=1
next prev parent reply other threads:[~2026-10-10 23:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-10 22:45 [PATCH bpf-next 0/5] bpf: Expose pinned arenas as sized bpffs files Andrea Righi
2026-10-10 22:45 ` [PATCH 1/5] bpf: Add an arena flag to retain allocated pages Andrea Righi
2026-10-10 23:00 ` sashiko-bot [this message]
2026-10-10 22:45 ` [PATCH 2/5] bpf: Expose pinned arenas as sized bpffs files Andrea Righi
2026-10-10 23:06 ` sashiko-bot
2026-10-10 23:40 ` bot+bpf-ci
2026-10-10 22:45 ` [PATCH 3/5] docs/bpf: Document pinned arena file mappings Andrea Righi
2026-10-10 23:19 ` bot+bpf-ci
2026-10-10 22:45 ` [PATCH 4/5] selftests/bpf: Test " Andrea Righi
2026-10-10 23:40 ` bot+bpf-ci
2026-10-10 22:46 ` [PATCH 5/5] selftests/bpf: Test two-way arena access with two guests Andrea Righi
2026-10-10 23:00 ` sashiko-bot
2026-10-10 23:40 ` bot+bpf-ci
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=sashiko-outbox-166916@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=arighi@nvidia.com \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@lists.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.