| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Skip tests that require net/netfilter/nft_set_pipapo support.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All tests under "tests/shell" are shell scripts with shebang /bin/bash
or /bin/sh. This may seem expected, since these tests are under
"tests/shell" directory, but any executable file would work.
Anyway. The vast majority of the tests has "#!/bin/bash" as shebang.
A few tests had "#!/bin/sh" or "#!/bin/sh -e". Unify this and always use bash.
Since we anyway require bash, this is not a limitation.
Also, if we know that this is a bash script (by parsing the shebang), we
can let the test wrapper pass "-x" to the script. The next commit will
do that, and it is nicer if the shebangs are all uniform.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's important to run (a part) of the tests in a timely manner.
Add an option to skip long running tests.
Thereby, add a more general NFT_TEST_SKIP_* mechanism.
This is related and inverse from "NFT_TEST_HAVE_json", where a test
can require [ "$NFT_TEST_HAVE_json" != n ] to run, but is skipped when
[ "$NFT_TEST_SKIP_slow" = y ].
Currently only NFT_TEST_SKIP_slow is supported. The user can set such
environment variables (or use the -Q|--quick command line option). The
configuration is printed in the test info.
Tests should check for [ "$NFT_TEST_SKIP_slow" = y ] so that the
variable has to be explicitly set to opt-out. For convenience, tests can
also add a
# NFT_TEST_SKIP(NFT_TEST_SKIP_slow)
tag, which is evaluated by test-wrapper.sh. Or they can run a quick, reduced
part of the test, but then should still indicate to be skipped.
Mark 8 tests are as slow, that take longer than 5 seconds on my machine.
With this, a parallel wall time for the non-slow tests is only 7 seconds
(on my machine).
The ultimate point is to integrate a call to "tests/shell/run-tests.sh"
in a `make check` target. For development, you can then export
NFT_TEST_SKIP_slow=y and have a fast `make check`.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
