From: bot+bpf-ci@kernel.org
To: chenyuan_fl@163.com,bpf@vger.kernel.org
Cc: linux-kernel@vger.kernel.org,ast@kernel.org,daniel@iogearbox.net,andrii@kernel.org,eddyz87@gmail.com,memxor@gmail.com,martin.lau@linux.dev,song@kernel.org,yonghong.song@linux.dev,jolsa@kernel.org,emil@etsalapatis.com,ihor.solodrai@linux.dev,chenyuan@kylinos.cn,ast@kernel.org,andrii@kernel.org,daniel@iogearbox.net,martin.lau@kernel.org,eddyz87@gmail.com,yonghong.song@linux.dev,clm@meta.com,ihor.solodrai@linux.dev
Subject: Re: [PATCH bpf-next v2 1/3] bpf, arena: fix range_tree_clear inconsistency on kmalloc_nolock failure
Date: Mon, 10 Aug 2026 10:45:10 +0000 (UTC) [thread overview]
Message-ID: <eef3da9def5fc191df9f954558e4ab6c114082534f6d8901a32393b70473db4f@mail.kernel.org> (raw)
In-Reply-To: <20260810094634.2723213-2-chenyuan_fl@163.com>
[-- Attachment #1: Type: text/plain, Size: 2199 bytes --]
> diff --git a/kernel/bpf/range_tree.c b/kernel/bpf/range_tree.c
> index 2f28886f3ff7..15b588377a76 100644
> --- a/kernel/bpf/range_tree.c
> +++ b/kernel/bpf/range_tree.c
> @@ -143,16 +143,22 @@ 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);
> rn->rn_last = start - 1;
> range_it_insert(rn, rt);
>
> - /* Add a range */
> - new_rn = kmalloc_nolock(sizeof(struct range_node), __GFP_ACCOUNT,
> - NUMA_NO_NODE);
> - if (!new_rn)
> - return -ENOMEM;
> + /* Add right-half range */
> new_rn->rn_start = last + 1;
> new_rn->rn_last = old_last;
> range_it_insert(new_rn, rt);
This isn't a bug, but could the changelog also state what went wrong
with the old ordering? The sibling patch d453da244bfd ("bpf, arena:
fix range_tree_set inconsistency on kmalloc_nolock failure") spells
out the consequence ("previously the overlapping nodes were already
removed by range_tree_clear() before the allocation was attempted,
permanently losing the cleared sub-ranges"), while this changelog only
describes the new behavior. Without explaining that the right sub-range
[last + 1, old_last] was permanently lost from the free tree when
kmalloc_nolock() failed after the left half had already been shrunk,
the two changelogs read inconsistently.
This looks like a bug fix for the original range_tree implementation.
Should this include:
Fixes: b795379757eb ("bpf: Introduce range_tree data structure and use it in bpf arena")
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/31377360587
next prev parent reply other threads:[~2026-08-10 10:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-10 9:46 [PATCH bpf-next v2 0/3] bpf, arena: fix range_tree consistency on allocation failure chenyuan_fl
2026-08-10 9:46 ` [PATCH bpf-next v2 1/3] bpf, arena: fix range_tree_clear inconsistency on kmalloc_nolock failure chenyuan_fl
2026-08-10 10:45 ` bot+bpf-ci [this message]
2026-08-10 9:46 ` [PATCH bpf-next v2 2/3] bpf, arena: fix range_tree_set " chenyuan_fl
2026-08-10 10:59 ` bot+bpf-ci
2026-08-10 9:46 ` [PATCH bpf-next v2 3/3] bpf, arena: check range_tree_set return in arena_free_pages and arena_free_worker chenyuan_fl
2026-08-10 10:59 ` 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=eef3da9def5fc191df9f954558e4ab6c114082534f6d8901a32393b70473db4f@mail.kernel.org \
--to=bot+bpf-ci@kernel.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=chenyuan@kylinos.cn \
--cc=chenyuan_fl@163.com \
--cc=clm@meta.com \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=ihor.solodrai@linux.dev \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®