Re: [PATCH net-next] selftests: icmp_redirect: remove xfail support

[Ido Schimmel <idosch@nvidia.com>]

On Mon, Sep 07, 2026 at 01:24:23PM +0000, Eric Dumazet wrote:
> Commit 0a36a75c6818 ("selftests: icmp_redirect: support expected failures")
> added xfail support to icmp_redirect.sh because IPv6 redirect tests
> (including the VRF variants) were failing due to bugs in the IPv6
> redirect logic.
> 
> Part of this was addressed in commit 0e02bf5de46a ("selftests:
> icmp_redirect: IPv6 PMTU info should be cleared after redirect"), which
> updated the test expectation that old PMTU information should be
> cleared following a redirect.
> 
> Recently, commit cd51b74bdd0b ("ipv6: Fix redirect exception creation for
> UDP/RAW sockets") fixed the underlying kernel bug in ip6_sk_redirect():
> previously, passing sk->sk_bound_dev_if caused exception creation to
> fail for sockets not bound to a device or bound to a VRF. Now that
> skb->dev->ifindex is used, redirect exceptions are created properly for
> UDP and RAW sockets, including in VRF environments.
> 
> With this fix in place, all IPv6 tests in icmp_redirect.sh pass as
> expected. Passing xfail=1 to log_test() for all IPv6 tests is no longer
> necessary and masks unexpected failures as XFAIL instead of FAIL.
> 
> Commit 3748939bce3f ("selftests: icmp_redirect: pass xfail=0 to log_test()")
> worked around a bash error caused by empty xfail arguments on IPv4 tests.
> 
> Remove the obsolete xfail support from log_test() and restore standard
> pass/fail reporting across all tests.
> 
> Tested:
> Tests passed:  40
> Tests failed:   0
> 
> Signed-off-by: Eric Dumazet <edumazet@google.com>

Reviewed-by: Ido Schimmel <idosch@nvidia.com>

FTR, I don't think cd51b74bdd0b ("ipv6: Fix redirect exception creation
for UDP/RAW sockets") is what fixed the xfail (I never saw xfail, even
before my patch). It's more likely that it was fixed by commit
0e02bf5de46a ("selftests: icmp_redirect: IPv6 PMTU info should be
cleared after redirect"):

1. The redirect message quotes an echo request, so it's going through
icmpv6_err() which calls ip6_redirect() using the correct oif. It's
possible that rawv6_err() later called ip6_sk_redirect(), but by then
the exception was already present / populated.

2. Both 0e02bf5de46a and 0a36a75c6818 mention the same test case: "mtu
exception plus redirect".