| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Mike Dillinger reported issues with insertion of entries into sets
supporting intervals that were denied because of false conflicts with
elements that were already expired. Partial failures would occur to,
leading to the generation of new intervals the user didn't specify,
as only the opening or the closing elements wouldn't be inserted.
The reproducer provided by Mike looks like this:
#!/bin/bash
nft list set ip filter blacklist4-ip-1m
for ((i=1;i<=10;i++)); do
nft add element filter blacklist4-ip-1m {$i.$i.$i.$i}
sleep 1
done
nft list set ip filter blacklist4-ip-1m
which, run in a loop at different intervals, show the different kind
of failures.
Extend the existing test case for overlapping and non-overlapping
intervals to systematically cover sets with a configured timeout.
As reported by Pablo, the test would fail if we keep a one-second
timeout if it runs on a "slow" kernel (e.g. with KASan), using the
libtool wrapper in src/nft as $NFT, because we can't issue 218
commands within one second. To avoid that, introduce an adaptive
timeout based on how many times we can list a single entry with a
fixed one-second timeout.
On a single 2.9GHz AMD Epyc 7351 thread:
test run nft commands/s timeout
- src/nft libtool wrapper, KASan: 68.4s 10 32s
- nft binary, KASan: 5.1s 168 2s
- src/nft libtool wrapper, w/o KASan: 18.3s 37 8s
- nft binary, w/o KASan: 2.4s 719 1s
While at it, fix expectation for insertion of '15-20 . 50-60' (it's
expected to succeed, given the list), and the reason why I didn't
notice: a simple command preceded by ! won't actually result in
the shell exiting, even if it fails. Add some clearer failure reports
too.
v2:
- adjust set timeouts to nft commands/s
- fix checks on expected outcome of insertions and reports
Reported-by: Mike Dillinger <miked@softtalker.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
|
non-overlapping ranges
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.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
