Re: [PATCH bpf-next v6 2/3] bpf, arena: fix range_tree_set inconsistency on kmalloc_nolock failure

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Tue, Sep 22, 2026 at 03:21 PM chenyuan_fl@163.com <chenyuan_fl@163.com> wrote:
> +	/*
> +	 * The pre-clear probe only decides whether a fresh node is needed;
> +	 * adjacency on either side is invariant across the clear, so it can
> +	 * run before the tree is modified and -ENOMEM leaves it untouched.
> +	 * The merge below re-fetches its handles after the clear instead of
> +	 * relying on the overlapping nodes being updated in place.
> +	 */
> +	left = range_it_iter_first(rt, start - 1, start - 1);
> +	right = range_it_iter_first(rt, last + 1, last + 1);
[...]
>  	/* Do we have a left-adjacent range ? */
>  	left = range_it_iter_first(rt, start - 1, start - 1);

In v4 I asked why the 2nd lookup is needed. It's not.
range_tree_clear() frees only the nodes that are entirely inside
[start, last]. A node that covers start - 1 or last + 1 is trimmed
in place. The split case cannot happen here because of the
'already set' check above. So left and right found before the clear
are the same nodes that the 2nd lookup returns.
Do the lookup once and drop the comment.