From: sashiko-bot@kernel.org
To: "Kumar Kartikeya Dwivedi" <memxor@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [RFC PATCH bpf-next v1 15/16] selftests/bpf: Test typed arena page allocation and release
Date: Sat, 26 Sep 2026 23:46:50 +0000 [thread overview]
Message-ID: <20260926234650.E609C1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260926233503.3114147-16-memxor@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] bpf: physical pages freed before TLB flush in typed_arena_alloc_pages()
- [High] bpf: bpf_typed_arena_free_pages() frees adjacent chunks due to unaligned addr
--
commit 45f79d175e13ad1f2540fd16c264cce33991c839
Author: Kumar Kartikeya Dwivedi <memxor@gmail.com>
selftests/bpf: Test typed arena page allocation and release
Allocate a page of typed arena objects, write one, reach it again through
an opaque copy of its address and its neighbour by arithmetic on that copy,
and check that the kfunc receives the registered typed arena in place of
the type ID. Take the chunk a value names and see the same chunk refused
twice, once for the chunk and once for a page inside it. Ask for one page
of an object that spans several and see the request rounded up to the
object's chunk, with the granted count written back. Release a chunk and
see it keep its objects and stay taken within the same invocation, since
the release is deferred behind a grace period.
Reject a use of the returned pointer without a NULL check, a struct without
special fields, and a map that is not the program's arena. Declare the two
kfuncs in bpf_experimental.h.
> diff --git a/tools/testing/selftests/bpf/progs/verifier_typed_arena.c b/tools/testing/selftests/bpf/progs/verifier_typed_arena.c
> index 808a65611d4ef..8ec75fd1f97bf 100644
> --- a/tools/testing/selftests/bpf/progs/verifier_typed_arena.c
> +++ b/tools/testing/selftests/bpf/progs/verifier_typed_arena.c
> @@ -1157,6 +1157,148 @@ int ptr_field_sanitize_on_one_path(void *ctx)
> return 0;
> }
>
> +#define TYPE_ID(T) bpf_core_type_id_local(T)
> +
> +SEC("syscall")
> +__description("allocated pages hold real objects, reachable through any value that lands in them")
> +__success __retval(0)
> +__xlated("r2 = 0x{{[0-9a-f]+[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]}}")
> +__xlated("call kernel-function")
> +int pages_alloc(void *ctx)
> +{
> + struct typed_obj *obj, *again, *next;
> + void *opaque;
> + __u32 cnt = 1;
> +
> + obj = bpf_typed_arena_alloc_pages(&arena, TYPE_ID(struct typed_obj), NULL, &cnt,
> + NUMA_NO_NODE);
[Severity: Critical]
Is it possible for physical pages to be freed before the TLB flush occurs?
Looking at typed_arena_alloc_pages() in kernel/bpf/arena.c, when an
allocation fails midway:
kernel/bpf/arena.c:typed_arena_alloc_pages() {
...
if (data.i)
apply_to_existing_page_range(&init_mm, data.start,
(unsigned long)data.i << PAGE_SHIFT,
apply_range_clear_typed_cb, &cdata);
free_pages_nolock(head, order);
goto back_out;
...
}
If a concurrent page fault occurs, can this result in the physical pages being
returned to the allocator before the TLB flush in the back_out path?
> + if (!obj)
> + return 1;
[ ... ]
> +SEC("syscall")
> +__description("a released chunk keeps its objects and stays taken until the grace period has passed")
> +__success __retval(0)
> +int pages_free(void *ctx)
> +{
> + struct typed_obj *obj;
> + __u32 cnt = 1;
> +
> + obj = bpf_typed_arena_alloc_pages(&arena, TYPE_ID(struct typed_obj), NULL, &cnt,
> + NUMA_NO_NODE);
> + if (!obj)
> + return 1;
> + obj->value = 7;
> + bpf_typed_arena_free_pages(&arena, TYPE_ID(struct typed_obj), obj, 1);
[Severity: High]
Does this code handle unaligned offset values correctly?
Looking at typed_arena_free_pages() in kernel/bpf/arena.c, when an unaligned
addr is passed, the calculation for the last chunk might spill over into the
next chunk:
kernel/bpf/arena.c:typed_arena_free_pages() {
off = addr - base;
if (page_cnt > (size - off) >> PAGE_SHIFT)
return;
first = off >> ta->chunk_shift;
last = (off + ((unsigned long)page_cnt << PAGE_SHIFT) - 1) >> ta->chunk_shift;
...
}
Can this lead to unintentional freeing of adjacent chunks?
> + if (obj->value != 7)
> + return 2;
> + cnt = 1;
> + if (bpf_typed_arena_alloc_pages(&arena, TYPE_ID(struct typed_obj), obj, &cnt, NUMA_NO_NODE))
> + return 3;
> + return 0;
> +}
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260926233503.3114147-1-memxor@gmail.com?part=15
next prev parent reply other threads:[~2026-09-26 23:46 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-26 23:34 [RFC PATCH bpf-next v1 00/16] BPF typed arenas Kumar Kartikeya Dwivedi
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 01/16] mm/vmalloc: Add get_vm_area_align() Kumar Kartikeya Dwivedi
2026-09-26 23:42 ` sashiko-bot
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 02/16] bpf: Introduce BPF typed arenas Kumar Kartikeya Dwivedi
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 03/16] bpf: Back typed arena chunks with scratch on demand Kumar Kartikeya Dwivedi
2026-09-26 23:56 ` sashiko-bot
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 04/16] bpf: Add the typed_arena_cast instruction Kumar Kartikeya Dwivedi
2026-09-26 23:55 ` sashiko-bot
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 05/16] bpf: Allow scalar and atomic access to typed arena objects Kumar Kartikeya Dwivedi
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 06/16] bpf: Support special fields in " Kumar Kartikeya Dwivedi
2026-09-26 23:59 ` sashiko-bot
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 07/16] bpf: Trust typed pointer fields of " Kumar Kartikeya Dwivedi
2026-09-27 0:03 ` sashiko-bot
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 08/16] bpf: Canonicalize loaded typed arena pointers where they are used Kumar Kartikeya Dwivedi
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 09/16] bpf: Add typed arena page allocation and release kfuncs Kumar Kartikeya Dwivedi
2026-09-26 23:55 ` sashiko-bot
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 10/16] bpf: Let typed_arena_cast copy pointers the verifier already trusts Kumar Kartikeya Dwivedi
2026-09-26 23:49 ` sashiko-bot
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 11/16] libbpf: Support the typed_arena_cast instruction Kumar Kartikeya Dwivedi
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 12/16] selftests/bpf: Build BPF objects with compiler-inserted typed arena casts Kumar Kartikeya Dwivedi
2026-09-26 23:46 ` sashiko-bot
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 13/16] selftests/bpf: Test typed arena casts and registration Kumar Kartikeya Dwivedi
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 14/16] selftests/bpf: Test typed arena object access, kptrs and typed pointer fields Kumar Kartikeya Dwivedi
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 15/16] selftests/bpf: Test typed arena page allocation and release Kumar Kartikeya Dwivedi
2026-09-26 23:46 ` sashiko-bot [this message]
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 16/16] selftests/bpf: Exercise typed arenas at run time Kumar Kartikeya Dwivedi
2026-09-26 23:50 ` sashiko-bot
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=20260926234650.E609C1F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=memxor@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox