From: Ali Firas <alishmery18@gmail.com>
To: netdev@vger.kernel.org, idosch@nvidia.com
Cc: kuba@kernel.org, pabeni@redhat.com, davem@davemloft.net,
edumazet@google.com, andrew+netdev@lunn.ch, horms@kernel.org,
razor@blackwall.org, roopa@nvidia.com, shuah@kernel.org,
linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
Ali Firas <alishmery18@gmail.com>
Subject: [PATCH net-next v3 6/6] selftests: net: test the vxlan vnifilter request limit and dump replay
Date: Mon, 28 Sep 2026 00:52:09 +0300 [thread overview]
Message-ID: <20260927215209.2581830-7-alishmery18@gmail.com> (raw)
In-Reply-To: <20260927215209.2581830-1-alishmery18@gmail.com>
Extend the vnifilter tests for the request-size limit, the 24-bit VNI
range, and the dump/replay round trip the limit requires.
The API test gains: the largest accepted add and one VNI past it; a
rejected oversized add and a rejected multi-entry add whose entries are
each under the limit but sum over it, each checked to install nothing
(the range is asserted absent first, since vxlan_vni_add() folds an
existing VNI into the update path and would return 0 either way). The cap
is symmetric, so it also checks a maximum-size delete accepted and a
max+1 delete rejected, with every VNI in the max+1 range installed first
so the refusal can only come from the cap; a within-cap delete of a
never-installed range, which must fail on the missing VNI; an inverted
range accepted as a no-op; and the 24-bit bound exercised through END,
not only START.
bridge(8) places one VXLAN_VNIFILTER_ENTRY per comma-separated item into
a single message, so the multi-entry case is reachable without a
hand-built netlink message.
vxlan_vnifilter_dump_replay() builds a contiguous run twice the limit
from two requests, then replays every range the dump reports into a
second device and requires all to be accepted and the two dumps to
match. Without the dump clamp the run dumps as one over-limit entry that
replay rejects; with it the run dumps as limit-sized entries that
replay.
vxlan_vnifilter_api() had no teardown of its own device and namespace;
add veth-host and the test netns to cleanup(), which runs on EXIT, so a
failing case does not leave them or its entries behind.
Suggested-by: Ido Schimmel <idosch@nvidia.com>
Assisted-by: LLM
Signed-off-by: Ali Firas <alishmery18@gmail.com>
---
Notes:
v3: was 5/5. Add the request-limit, 24-bit-range, symmetric-delete and dump/replay cases; give the test its own netns teardown.
.../selftests/net/test_vxlan_vnifiltering.sh | 114 +++++++++++++++++-
1 file changed, 113 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/net/test_vxlan_vnifiltering.sh b/tools/testing/selftests/net/test_vxlan_vnifiltering.sh
index 8deacc565afa..f48bc861bb88 100755
--- a/tools/testing/selftests/net/test_vxlan_vnifiltering.sh
+++ b/tools/testing/selftests/net/test_vxlan_vnifiltering.sh
@@ -84,6 +84,7 @@ ret=0
# all tests in this script. Can be overridden with -t option
TESTS="
vxlan_vnifilter_api
+ vxlan_vnifilter_dump_replay
vxlan_vnifilter_datapath
vxlan_vnifilter_datapath_pervni
vxlan_vnifilter_datapath_mgroup
@@ -163,8 +164,9 @@ check_vm_connectivity() {
cleanup() {
ip link del veth-hv-1 2>/dev/null || true
ip link del vethhv-11 vethhv-12 vethhv-21 vethhv-22 2>/dev/null || true
+ ip link del veth-host 2>/dev/null || true
- cleanup_ns $hv_1 $hv_2 $vm_11 $vm_21 $vm_12 $vm_22 $vm_31 $vm_32
+ cleanup_ns $hv_1 $hv_2 $vm_11 $vm_21 $vm_12 $vm_22 $vm_31 $vm_32 $testns
}
trap cleanup EXIT
@@ -371,6 +373,116 @@ vxlan_vnifilter_api()
# change vxlan vnifilter flag
run_cmd "ip -netns $testns link set dev vxlan-ext1 type vxlan external novnifilter"
log_test $? 2 "Cannot unset vnifilter flag on a device"
+
+ # A single request may add at most 4096 VNIs. bridge(8) puts one
+ # VXLAN_VNIFILTER_ENTRY per comma-separated item into a single message,
+ # so both the single-entry and the multi-entry paths are reachable here.
+
+ # The largest accepted add, and one VNI more rejected.
+ run_cmd "bridge -netns $testns vni add dev vxlan-ext1 vni 10000-14095"
+ log_test $? 0 "Add a request of the maximum VNI count"
+
+ # The rejected oversized add must install nothing. Assert the range is
+ # absent first: vxlan_vni_add() folds an already-present VNI into the
+ # update path and returns 0, so a later probe cannot tell "installed
+ # nothing" from "installed part" unless it started absent.
+ run_cmd "bridge -netns $testns vni show dev vxlan-ext1 | grep -qw 20000"
+ log_test $? 1 "VNI 20000 absent before the oversized add"
+ run_cmd "bridge -netns $testns vni add dev vxlan-ext1 vni 20000-24096"
+ log_test $? 255 "Cannot add a request over the maximum VNI count"
+ run_cmd "bridge -netns $testns vni show dev vxlan-ext1 | grep -qw 20000"
+ log_test $? 1 "The rejected oversized add installed nothing"
+
+ # Two entries each under the limit but summing over it: the per-message
+ # total is what is bounded, not the span of one entry. This is the shape
+ # a per-entry check would have let through.
+ run_cmd "bridge -netns $testns vni show dev vxlan-ext1 | grep -qw 30000"
+ log_test $? 1 "VNI 30000 absent before the oversized multi-entry add"
+ run_cmd "bridge -netns $testns vni add dev vxlan-ext1 vni 30000-32047,32048-34097"
+ log_test $? 255 "Cannot add a multi-entry request summing over the maximum"
+ run_cmd "bridge -netns $testns vni show dev vxlan-ext1 | grep -qw 30000"
+ log_test $? 1 "The rejected multi-entry add installed nothing"
+
+ # The cap is symmetric: a delete may touch at most the maximum too.
+ # Install a maximum-size range and the VNI past it, so the max+1 delete
+ # below has every VNI present and can only be refused by the cap, not by
+ # a missing VNI.
+ run_cmd "bridge -netns $testns vni add dev vxlan-ext1 vni 40000-44095"
+ log_test $? 0 "Populate a maximum-size range to delete"
+ run_cmd "bridge -netns $testns vni add dev vxlan-ext1 vni 44096"
+ log_test $? 0 "Add the VNI past the maximum range"
+ run_cmd "bridge -netns $testns vni del dev vxlan-ext1 vni 40000-44096"
+ log_test $? 255 "Cannot delete a request over the maximum VNI count"
+ run_cmd "bridge -netns $testns vni del dev vxlan-ext1 vni 40000-44095"
+ log_test $? 0 "Delete a request of the maximum VNI count"
+ run_cmd "bridge -netns $testns vni del dev vxlan-ext1 vni 44096"
+ log_test $? 0 "Delete the VNI past the maximum range"
+
+ # A within-cap delete of a never-installed range reaches the handler and
+ # fails there on the missing VNI, not on the cap.
+ run_cmd "bridge -netns $testns vni del dev vxlan-ext1 vni 50000-50010"
+ log_test $? 255 "Cannot delete a range that was never installed"
+
+ # A start above the end selects nothing and is accepted as a no-op.
+ # Use a VNI no earlier case installs, so the absence check is meaningful.
+ run_cmd "bridge -netns $testns vni show dev vxlan-ext1 | grep -qw 55000"
+ log_test $? 1 "VNI 55000 absent before the inverted range"
+ run_cmd "bridge -netns $testns vni add dev vxlan-ext1 vni 55000-50000"
+ log_test $? 0 "An inverted range is accepted as a no-op"
+ run_cmd "bridge -netns $testns vni show dev vxlan-ext1 | grep -qw 55000"
+ log_test $? 1 "The inverted range installed nothing"
+
+ # The VXLAN header carries 24 bits. The bound is on both endpoints, so a
+ # range whose END alone leaves the space is rejected too.
+ run_cmd "bridge -netns $testns vni add dev vxlan-ext1 vni 16777215"
+ log_test $? 0 "Add the highest VNI the header can carry"
+ run_cmd "bridge -netns $testns vni del dev vxlan-ext1 vni 16777215"
+ log_test $? 0 "Delete the highest VNI the header can carry"
+ run_cmd "bridge -netns $testns vni add dev vxlan-ext1 vni 16777215-16777216"
+ log_test $? 255 "Cannot add a range whose END leaves the 24-bit space"
+ run_cmd "bridge -netns $testns vni add dev vxlan-ext1 vni 100-4294967295"
+ log_test $? 255 "Cannot add a range whose END wraps past the 24-bit space"
+}
+
+# A device may hold a contiguous run longer than one request's limit, built
+# from several requests. The dump coalesces it, so the dump must break the run
+# into entries each no larger than the limit, or the configuration it reports
+# cannot be replayed. Install such a run, then feed every range the dump
+# reports back into a second device and require all to be accepted.
+vxlan_vnifilter_dump_replay()
+{
+ local opts="external vnifilter local 172.16.0.1 dev veth-testns"
+ local range rc=0 src_ranges dst_ranges
+
+ cleanup_vnifilter_api &>/dev/null
+ setup_vnifilter_api
+
+ # The destination is on a different dstport so re-adding the same VNIs
+ # does not collide with the source under vxlan_vni_in_use().
+ run_cmd "ip -netns $testns link add vxlan-src type vxlan $opts dstport 4789"
+ log_test $? 0 "dump/replay: create source device"
+ run_cmd "ip -netns $testns link add vxlan-dst type vxlan $opts dstport 4790"
+ log_test $? 0 "dump/replay: create destination device"
+
+ # 8192 contiguous VNIs sharing the default remote: one run, twice the
+ # limit, installed in two accepted requests.
+ run_cmd "bridge -netns $testns vni add dev vxlan-src vni 10000-14095"
+ run_cmd "bridge -netns $testns vni add dev vxlan-src vni 14096-18191"
+ log_test $? 0 "dump/replay: populate a run larger than the limit"
+
+ for range in $(bridge -netns $testns vni show dev vxlan-src | \
+ grep -oE '[0-9]+-[0-9]+|[0-9]{2,}'); do
+ bridge -netns $testns vni add dev vxlan-dst vni "$range" \
+ 2>/dev/null || rc=$?
+ done
+ log_test $rc 0 "dump/replay: every dumped entry is accepted on replay"
+
+ src_ranges=$(bridge -netns $testns vni show dev vxlan-src | \
+ grep -oE '[0-9]+-[0-9]+|[0-9]{2,}' | sort)
+ dst_ranges=$(bridge -netns $testns vni show dev vxlan-dst | \
+ grep -oE '[0-9]+-[0-9]+|[0-9]{2,}' | sort)
+ [ -n "$src_ranges" ] && [ "$src_ranges" = "$dst_ranges" ]
+ log_test $? 0 "dump/replay: source and destination dump the same ranges"
}
# Sanity test vnifilter datapath
--
2.53.0
next prev parent reply other threads:[~2026-09-27 21:54 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-27 21:52 [PATCH net-next v3 0/6] vxlan: vnifilter: bound a single request and account per-VNI memory Ali Firas
2026-09-27 21:52 ` [PATCH net-next v3 1/6] vxlan: vnifilter: validate the VXLAN_VNIFILTER_ENTRY nest Ali Firas
2026-09-30 3:52 ` netdev-bot+sashiko
2026-09-27 21:52 ` [PATCH net-next v3 2/6] vxlan: vnifilter: reject VNIs outside the 24-bit space Ali Firas
2026-09-30 3:52 ` netdev-bot+sashiko
2026-09-27 21:52 ` [PATCH net-next v3 3/6] vxlan: vnifilter: bound the number of VNIs one request may touch Ali Firas
2026-09-30 3:52 ` netdev-bot+sashiko
2026-09-27 21:52 ` [PATCH net-next v3 4/6] vxlan: vnifilter: clamp the dumped VNI range to the request limit Ali Firas
2026-09-30 3:52 ` netdev-bot+sashiko
2026-09-27 21:52 ` [PATCH net-next v3 5/6] vxlan: vnifilter: account per-VNI memory to memcg Ali Firas
2026-09-30 3:52 ` netdev-bot+sashiko
2026-09-27 21:52 ` Ali Firas [this message]
2026-09-30 3:52 ` [PATCH net-next v3 6/6] selftests: net: test the vxlan vnifilter request limit and dump replay netdev-bot+sashiko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260927215209.2581830-7-alishmery18@gmail.com \
--to=alishmery18@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=idosch@nvidia.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=razor@blackwall.org \
--cc=roopa@nvidia.com \
--cc=shuah@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®