Re: [nf_tables] rbtree interval set: in one batch, re-adding element E0 makes deleting an unrelated interval E1 fail with -ENOENT

On Tue, Aug 11, 2026 at 05:22:01PM +0800, Wei Fang wrote:
[...]
> Problem
> -------
> On an interval set that already contains two intervals, one batch
> that does both of the following fails on the second operation:
> 
> 1. re-add element E0 without NLM_F_EXCL (update semantics);
> 2. delete a different interval E1.
> 
> The delete returns -ENOENT.  Sending the same two operations in
> separate messages succeeds.  A transaction must not change what an
> operation does: batched and unbatched execution must behave the same.
> 
> Steps to reproduce
> ------------------
> One batch on an ipv4_addr INTERVAL set with two existing intervals:
> 
> 1. re-add E0 = [10.0.1.0..10.0.2.0) without NLM_F_EXCL;
> 2. delete E1 = [10.0.2.0..10.0.3.0).
> 
> Raw netlink is required: the nft CLI re-sorts interval elements and
> hides the ordering.

What do you mean by "hides the ordering"? It sounds negative, actually
what is does is to pass a list of elements to the kernel that make
sense when interpreting the interval?

Ordering is paramount in this loose interface, your program does:

        ...
        put_interval_elem(&q, 0, E1_END, 1);
        put_interval_elem(&q, 1, E1, 0);

Deleting E1_END element before E1, makes no sense, the interval
representation is reversed.