Re: [nf_tables] pipapo: inserting an interval that strictly contains an existing one is accepted; rbtree rejects the same insert

Hi,

Thanks for the detailed explanation.  I agree with the
auto-merge/no-op behaviour for the case you described: with an
existing interval 10.0.0.1-10.0.0.5, adding 10.0.0.2 (an element
fully contained in the interval) being a no-op is the expected
default.  The reported sequence is the opposite containment
direction, so I would like to make sure we are talking about the
same case.

The report is about inserting a *new interval that strictly
contains an existing one*.  On a pipapo set: first insert
[1.1.1.1..1.1.1.11), then insert [1.1.1.0..1.1.1.12).
On the kernel under test:

- the second insert is accepted (errno 0);
- the new interval is actually added, it is not a no-op: a raw
  GETSETELEM dump afterwards lists two elements,
  [1.1.1.1..1.1.1.11) and [1.1.1.0..1.1.1.12), side by side;
- the identical sequence on an rbtree interval set is rejected
  with -EEXIST.

So in this direction the set ends up containing two overlapping
intervals, which makes membership lookups ambiguous for keys in the
overlap region.  (As a side effect, `nft list set` aborts with an
assertion failure on such a set - userspace interval aggregation
does not expect overlapping intervals to exist.)

If accepting this direction is intentional - i.e. the two backends
are deliberately allowed to behave differently here - that is fine;
I would just like to confirm that this is intended behaviour rather
than a gap in the pipapo overlap check.

On Tue, Aug 11, 2026 at 6:49 PM Florian Westphal <[email protected]> wrote:
>
> Wei Fang <[email protected]> wrote:
> > On Tue, Aug 11, 2026 at 6:20 PM Florian Westphal <[email protected]> wrote:
> > >
> > > Wei Fang <[email protected]> wrote:
> > > > -------------------
> > > > expected: both backends reject the overlapping insert (-EEXIST)
> > >
> > > Why?
>
> Maybe I was too terse.  Default behaviour for interval sets (Rbtree) is
> auto-merge: if we have 10.0.0.1-10.0.0.5, add for 10.0.0.2 will work
> (no-op).
>
> Behaviour for pipapo is to accept a new element that is fully contained
> in an existing entry (no add takes place).
>
> Sure, it could be changed to reject but that would alter user-visible
> behaviour, so I would expect complaints.