On Thu, Mar 05, 2020 at 09:34:11PM +0100, Stefano Brivio wrote: > Insertion of overlapping ranges should return success only if the new > elements are identical to existing ones, or, for concatenated ranges, > if the new element is less specific (in all its fields) than any > existing one. > > Note that, in case the range is identical to an existing one, insertion > won't actually be performed, but no error will be returned either on > 'add element'. > > This was inspired by a failing case reported by Phil Sutter (where > concatenated overlapping ranges would fail insertion silently) and is > fixed by kernel series with subject: > nftables: Consistently report partial and entire set overlaps > > With that series, these tests now pass also if the call to set_overlap() > on insertion is skipped. Partial or entire overlapping was already > detected by the kernel for concatenated ranges (nft_set_pipapo) from > the beginning, and that series makes the nft_set_rbtree implementation > consistent in terms of detection and reporting. Without that, overlap > checks are performed by nft but not guaranteed by the kernel. > > However, we can't just drop set_overlap() now, as we need to preserve > compatibility with older kernels. Applied, thanks.
