From: sashiko-bot@kernel.org
To: chenyuan_fl@163.com
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v1 1/3] bpf, arena: fix range_tree_clear inconsistency on kmalloc_nolock failure
Date: Thu, 06 Aug 2026 03:14:55 +0000 [thread overview]
Message-ID: <20260806031455.E06D31F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260806030359.299480-2-chenyuan_fl@163.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] `range_tree_set()` suffers from the exact same partial-modification flaw that the patch fixes in `range_tree_clear()`, leading to permanent arena slot leaks.
--
--- Patch [1]: [PATCH bpf-next v1 1/3] bpf, arena: fix range_tree_clear inconsistency on kmalloc_nolock failure ---
commit 8092890527e00050d54d5c7b5deedf81e64396d7
Author: Yuan Chen <chenyuan@kylinos.cn>
bpf, arena: fix range_tree_clear inconsistency on kmalloc_nolock failure
This patch addresses an inconsistency in range_tree_clear() where memory
allocation failures could leave the range tree partially modified. It fixes
this by pre-allocating the required node before altering the tree structure.
> diff --git a/kernel/bpf/range_tree.c b/kernel/bpf/range_tree.c
> index 2f28886f3ff75..24fa32d4356bb 100644
> --- a/kernel/bpf/range_tree.c
> +++ b/kernel/bpf/range_tree.c
> @@ -143,16 +143,21 @@ int range_tree_clear(struct range_tree *rt, u32 start, u32 len)
> if (rn->rn_start < start && rn->rn_last > last) {
> u32 old_last = rn->rn_last;
>
> + /* Pre-allocate the right-half node before modifying
> + * the tree. If allocation fails we return -ENOMEM
> + * without altering the range tree.
> + */
> + new_rn = kmalloc_nolock(sizeof(struct range_node),
> + __GFP_ACCOUNT, NUMA_NO_NODE);
> + if (!new_rn)
> + return -ENOMEM;
> +
> /* Overlaps with the entire clearing range */
> range_it_remove(rn, rt);
[Severity: High]
This isn't a bug introduced by this patch, but does range_tree_set()
suffer from the exact same partial-modification flaw?
Looking at range_tree_set() in kernel/bpf/range_tree.c, it also modifies the
tree before attempting an allocation:
/* Clear out everything in the range we want to set. */
err = range_tree_clear(rt, start, len);
if (err)
return err;
...
} else {
left = kmalloc_nolock(sizeof(struct range_node), __GFP_ACCOUNT, NUMA_NO_NODE);
if (!left)
return -ENOMEM;
If kmalloc_nolock() fails here, the function returns -ENOMEM but leaves the
tree with the overlapping nodes already deleted by range_tree_clear(). Any
previously free sub-ranges that were cleared could be permanently lost.
Furthermore, in kernel/bpf/arena.c, arena_free_pages() appears to ignore the
return value entirely:
range_tree_set(&arena->rt, pgoff, page_cnt);
Could an allocation failure here result in a silent, permanent leak of arena
virtual address space?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260806030359.299480-1-chenyuan_fl@163.com?part=1
next prev parent reply other threads:[~2026-08-06 3:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-06 3:03 [PATCH bpf-next v1 0/3] bpf, arena: keep range tree consistent on kmalloc_nolock failure chenyuan_fl
2026-08-06 3:03 ` [PATCH bpf-next v1 1/3] bpf, arena: fix range_tree_clear inconsistency " chenyuan_fl
2026-08-06 3:14 ` sashiko-bot [this message]
2026-08-06 3:03 ` [PATCH bpf-next v1 2/3] bpf, arena: fix range_tree_set " chenyuan_fl
2026-08-06 3:03 ` [PATCH bpf-next v1 3/3] bpf, arena: check range_tree_set return in arena_free_pages and arena_free_worker chenyuan_fl
2026-08-06 3:19 ` 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=20260806031455.E06D31F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=chenyuan_fl@163.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