kernel/linux.git/tools/testing/selftests/net, branch v7.0-rc7

selftests: netfilter: nft_concat_range.sh: add check for flush+reload bug

2026-03-25T20:40:47+00:00

This test will fail without the preceding commit ("netfilter: nft_set_pipapo_avx2: fix match retart if found element is expired"): reject overlapping range on add 0s [ OK ] reload with flush /dev/stdin:59:32-52: Error: Could not process rule: File exists add element inet filter test { 10.0.0.29 . 10.0.2.29 } Reviewed-by: Stefano Brivio Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso

selftest: net: Add GC test for temporary routes with exceptions.

2026-03-23T23:59:31+00:00

Without the prior commit, IPv6 GC cannot track exceptions tied to permanent routes if they were originally added as temporary routes. Let's add a test case for the issue. 1. Add temporary routes 2. Create exceptions for the temporary routes 3. Promote the routes to permanent routes 4. Check if GC can find and purge the exceptions A few notes: + At step 4, unlike other test cases, we cannot wait for $GC_WAIT_TIME. While the exceptions are always iterable via netlink (since it traverses the entire fib tree instead of tb6_gc_hlist), rt6_nh_dump_exceptions() skips expired entries. If we waited for the expiration time, we would be unable to distinguish whether the exceptions were truly purged by GC or just hidden due to being expired. + For the same reason, at step 2, we use ICMPv6 redirect message instead of Packet Too Big message. This is because MTU exceptions always have RTF_EXPIRES, and rt6_age_examine_exception() does not respect the period specified by net.ipv6.route.flush=1. + We add a neighbour entry for the redirect target with NTF_ROUTER. Without this, the exceptions would be removed at step 3 when the fib6_may_remove_gc_list() is called. Without the fix, the exceptions remain even after GC is triggered by sysctl -wq net.ipv6.route.flush=1. FAIL: Expected 0 routes, got 5 TEST: ipv6 route garbage collection (promote to permanent routes) [FAIL] With the fix, GC purges the exceptions properly. TEST: ipv6 route garbage collection (promote to permanent routes) [ OK ] Signed-off-by: Kuniyuki Iwashima Reviewed-by: David Ahern Link: https://patch.msgid.link/20260320072317.2561779-4-kuniyu@google.com Signed-off-by: Jakub Kicinski

selftests: rtnetlink: add neighbour update test

2026-03-12T02:04:55+00:00

Check that protocol and flags are updated correctly for neighbour and pneigh entries. Signed-off-by: Sabrina Dubroca Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/d28f72b5b4ff4c9ecbbbde06146a938dcc4c264a.1772894876.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski

selftests: net: add test for IPv4 route with loopback IPv6 nexthop

2026-03-05T15:53:17+00:00

Add a regression test for a kernel panic that occurs when an IPv4 route references an IPv6 nexthop object created on the loopback device. The test creates an IPv6 nexthop on lo, binds an IPv4 route to it, then triggers a route lookup via ping to verify the kernel does not crash. ./fib_nexthops.sh Tests passed: 249 Tests failed: 0 Reviewed-by: Ido Schimmel Signed-off-by: Jiayuan Chen Reviewed-by: David Ahern Link: https://patch.msgid.link/20260304113817.294966-3-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski

selftests: net: tun: don't abort XFAIL cases

2026-03-05T15:34:55+00:00

The tun UDP tunnel GSO fixture contains XFAIL-marked variants intended to exercise failure paths (e.g. EMSGSIZE / "Message too long"). Using ASSERT_EQ() in these tests aborts the subtest, which prevents the harness from classifying them as XFAIL and can make the overall net: tun test fail. Switch the relevant ASSERT_EQ() checks to EXPECT_EQ() so the subtests continue running and the failures are correctly reported and accounted as XFAIL where applicable. Signed-off-by: Sun Jian Link: https://patch.msgid.link/20260225111451.347923-2-sun.jian.kdev@gmail.com Signed-off-by: Jakub Kicinski

selftests: mptcp: join: check removing signal+subflow endp

2026-03-05T02:21:13+00:00

This validates the previous commit: endpoints with both the signal and subflow flags should always be marked as used even if it was not possible to create new subflows due to the MPTCP PM limits. For this test, an extra endpoint is created with both the signal and the subflow flags, and limits are set not to create extra subflows. In this case, an ADD_ADDR is sent, but no subflows are created. Still, the local endpoint is marked as used, and no warning is fired when removing the endpoint, after having sent a RM_ADDR. The 'Fixes' tag here below is the same as the one from the previous commit: this patch here is not fixing anything wrong in the selftests, but it validates the previous fix for an issue introduced by this commit ID. Fixes: 85df533a787b ("mptcp: pm: do not ignore 'subflow' if 'signal' flag is also set") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260303-net-mptcp-misc-fixes-7-0-rc2-v1-5-4b5462b6f016@kernel.org Signed-off-by: Jakub Kicinski

selftests: mptcp: join: check RM_ADDR not sent over same subflow

2026-03-05T02:21:12+00:00

This validates the previous commit: RM_ADDR were sent over the first found active subflow which could be the same as the one being removed. It is more likely to loose this notification. For this check, RM_ADDR are explicitly dropped when trying to send them over the initial subflow, when removing the endpoint attached to it. If it is dropped, the test will complain because some RM_ADDR have not been received. Note that only the RM_ADDR are dropped, to allow the linked subflow to be quickly and cleanly closed. To only drop those RM_ADDR, a cBPF byte code is used. If the IPTables commands fail, that's OK, the tests will continue to pass, but not validate this part. This can be ignored: another subtest fully depends on such command, and will be marked as skipped. The 'Fixes' tag here below is the same as the one from the previous commit: this patch here is not fixing anything wrong in the selftests, but it validates the previous fix for an issue introduced by this commit ID. Fixes: 8dd5efb1f91b ("mptcp: send ack for rm_addr") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260303-net-mptcp-misc-fixes-7-0-rc2-v1-3-4b5462b6f016@kernel.org Signed-off-by: Jakub Kicinski

selftests: mptcp: more stable simult_flows tests

2026-03-05T02:21:12+00:00

By default, the netem qdisc can keep up to 1000 packets under its belly to deal with the configured rate and delay. The simult flows test-case simulates very low speed links, to avoid problems due to slow CPUs and the TCP stack tend to transmit at a slightly higher rate than the (virtual) link constraints. All the above causes a relatively large amount of packets being enqueued in the netem qdiscs - the longer the transfer, the longer the queue - producing increasingly high TCP RTT samples and consequently increasingly larger receive buffer size due to DRS. When the receive buffer size becomes considerably larger than the needed size, the tests results can flake, i.e. because minimal inaccuracy in the pacing rate can lead to a single subflow usage towards the end of the connection for a considerable amount of data. Address the issue explicitly setting netem limits suitable for the configured link speeds and unflake all the affected tests. Fixes: 1a418cb8e888 ("mptcp: simult flow self-tests") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260303-net-mptcp-misc-fixes-7-0-rc2-v1-1-4b5462b6f016@kernel.org Signed-off-by: Jakub Kicinski

selftests/net: packetdrill: restore tcp_rcv_big_endseq.pkt

2026-03-03T02:47:46+00:00

Commit 1cc93c48b5d7 ("selftests/net: packetdrill: remove tests for tcp_rcv_*big") removed the test for the reverted commit 1d2fbaad7cd8 ("tcp: stronger sk_rcvbuf checks") but also the one for commit 9ca48d616ed7 ("tcp: do not accept packets beyond window"). Restore the test with the necessary adaptation: expect a delayed ACK instead of an immediate one, since tcp_can_ingest() does not fail anymore for the last data packet. Signed-off-by: Simon Baatz Link: https://patch.msgid.link/20260301-tcp_rcv_big_endseq-v1-1-86ab7415ab58@gmail.com Signed-off-by: Jakub Kicinski

selftests/net: packetdrill: remove tests for tcp_rcv_*big

2026-02-28T15:55:52+00:00

Since commit 1d2fbaad7cd8 ("tcp: stronger sk_rcvbuf checks") has been reverted we need to remove the corresponding tests. Link: https://lore.kernel.org/20260227003359.2391017-1-kuba@kernel.org Link: https://patch.msgid.link/20260227033446.2596457-1-kuba@kernel.org Signed-off-by: Jakub Kicinski