The IPv4 FOU/GRETAP multicast test requires the fou module to register
tunnel encapsulation operations and the FOU generic netlink family.
Since there is no genetlink module alias, the module cannot be auto-loaded.

The test previously assumed CONFIG_NET_FOU=y. On kernels built with
CONFIG_NET_FOU=m, setup_ipv4() fails silently without terminating the
script, causing a false positive test failure with 0/100 received packets.

Fix this by trying to load the fou module before the IPv4 test. Skip the
subtest cleanly if the module is unavailable, mirroring the existing
IPv6 fou6 module handling and following pmtu.sh conventions.

Only module load failures result in a skip. Any other setup errors still
report a test failure, preserving test coverage.

The official selftest config enables CONFIG_NET_FOU=y, but many
distribution kernels build it as a module. modprobe is a no-op for
built-in configurations, so existing CI behavior remains unchanged.

Fixes: e5382133c51c ("selftests: net: add FOU multicast encapsulation resubmit test")
Signed-off-by: Qingshuang Fu <fuqingshuang@kylinos.cn>
---
 tools/testing/selftests/net/fou_mcast_encap.sh | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/tools/testing/selftests/net/fou_mcast_encap.sh b/tools/testing/selftests/net/fou_mcast_encap.sh
index 70210d39fba3..d94c19237daf 100755
--- a/tools/testing/selftests/net/fou_mcast_encap.sh
+++ b/tools/testing/selftests/net/fou_mcast_encap.sh
@@ -51,8 +51,6 @@ setup_common() {
 }
 
 setup_ipv4() {
-	# IPv4 FOU (CONFIG_NET_FOU) is built in on kernels configured for
-	# these tests, so no module load is needed here.
 	ip -n "$NSENDER" addr add 10.0.0.1/24 dev veth_s
 	ip -n "$NRECV" addr add 10.0.0.2/24 dev veth_r
 
@@ -160,8 +158,17 @@ run_ping_test() {
 }
 
 setup_common
-setup_ipv4
-run_ping_test -4 eoudp4 "$TUN4_R" "FOU/GRETAP IPv4 multicast encap resubmit"
+
+# The fou module registers both the tunnel encap ops used by "encap fou"
+# and the FOU genetlink family used by "ip fou add", and neither of them
+# is auto-loaded. modprobe succeeds as a no-op when CONFIG_NET_FOU=y.
+# Keep any other setup error as a test failure rather than a skip.
+if modprobe -q fou; then
+	setup_ipv4
+	run_ping_test -4 eoudp4 "$TUN4_R" "FOU/GRETAP IPv4 multicast encap resubmit"
+else
+	log_test_skip "FOU/GRETAP IPv4 multicast encap resubmit"
+fi
 
 if setup_ipv6; then
 	run_ping_test -6 eoudp6 "$TUN6_R" "FOU/ip6gretap IPv6 multicast encap resubmit"

base-commit: 08df884136f1c1197bab2a27814404fd329d9aac
-- 
2.25.1

On Fri, 11 Sep 2026 18:01:58 +0800 Qingshuang Fu wrote:
> Fixes: e5382133c51c ("selftests: net: add FOU multicast encapsulation resubmit test")

No fixes tag, please, this is barely worth applying at all, let along
as a fix.

> diff --git a/tools/testing/selftests/net/fou_mcast_encap.sh b/tools/testing/selftests/net/fou_mcast_encap.sh
> index 70210d39fba3..d94c19237daf 100755
> --- a/tools/testing/selftests/net/fou_mcast_encap.sh
> +++ b/tools/testing/selftests/net/fou_mcast_encap.sh
> @@ -51,8 +51,6 @@ setup_common() {
>  }
>  
>  setup_ipv4() {
> -	# IPv4 FOU (CONFIG_NET_FOU) is built in on kernels configured for
> -	# these tests, so no module load is needed here.
>  	ip -n "$NSENDER" addr add 10.0.0.1/24 dev veth_s
>  	ip -n "$NRECV" addr add 10.0.0.2/24 dev veth_r
>  
> @@ -160,8 +158,17 @@ run_ping_test() {
>  }
>  
>  setup_common
> -setup_ipv4
> -run_ping_test -4 eoudp4 "$TUN4_R" "FOU/GRETAP IPv4 multicast encap resubmit"
> +
> +# The fou module registers both the tunnel encap ops used by "encap fou"
> +# and the FOU genetlink family used by "ip fou add", and neither of them
> +# is auto-loaded. modprobe succeeds as a no-op when CONFIG_NET_FOU=y.
> +# Keep any other setup error as a test failure rather than a skip.

Drop this comment please, its obvious. Well, to people with basic
kernel familiarity it is.

> +if modprobe -q fou; then
> +	setup_ipv4
> +	run_ping_test -4 eoudp4 "$TUN4_R" "FOU/GRETAP IPv4 multicast encap resubmit"
> +else
> +	log_test_skip "FOU/GRETAP IPv4 multicast encap resubmit"
> +fi

Two very important questions you must answer before posting v2 or any
other similar fix:

Have you actually run into this or it's a result of an LLM scan?

How many of such fixes would we need to make all the net/ tests 
clean from similar issues?

在 2026/9/17 08:40, Jakub Kicinski 写道:
> On Fri, 11 Sep 2026 18:01:58 +0800 Qingshuang Fu wrote:
>> Fixes: e5382133c51c ("selftests: net: add FOU multicast encapsulation resubmit test")
> 
> No fixes tag, please, this is barely worth applying at all, let along
> as a fix.
> 
>> diff --git a/tools/testing/selftests/net/fou_mcast_encap.sh b/tools/testing/selftests/net/fou_mcast_encap.sh
>> index 70210d39fba3..d94c19237daf 100755
>> --- a/tools/testing/selftests/net/fou_mcast_encap.sh
>> +++ b/tools/testing/selftests/net/fou_mcast_encap.sh
>> @@ -51,8 +51,6 @@ setup_common() {
>>   }
>>   
>>   setup_ipv4() {
>> -	# IPv4 FOU (CONFIG_NET_FOU) is built in on kernels configured for
>> -	# these tests, so no module load is needed here.
>>   	ip -n "$NSENDER" addr add 10.0.0.1/24 dev veth_s
>>   	ip -n "$NRECV" addr add 10.0.0.2/24 dev veth_r
>>   
>> @@ -160,8 +158,17 @@ run_ping_test() {
>>   }
>>   
>>   setup_common
>> -setup_ipv4
>> -run_ping_test -4 eoudp4 "$TUN4_R" "FOU/GRETAP IPv4 multicast encap resubmit"
>> +
>> +# The fou module registers both the tunnel encap ops used by "encap fou"
>> +# and the FOU genetlink family used by "ip fou add", and neither of them
>> +# is auto-loaded. modprobe succeeds as a no-op when CONFIG_NET_FOU=y.
>> +# Keep any other setup error as a test failure rather than a skip.
> 
> Drop this comment please, its obvious. Well, to people with basic
> kernel familiarity it is.
> 
>> +if modprobe -q fou; then
>> +	setup_ipv4
>> +	run_ping_test -4 eoudp4 "$TUN4_R" "FOU/GRETAP IPv4 multicast encap resubmit"
>> +else
>> +	log_test_skip "FOU/GRETAP IPv4 multicast encap resubmit"
>> +fi
> 
> Two very important questions you must answer before posting v2 or any
> other similar fix:
> 
> Have you actually run into this or it's a result of an LLM scan?
> 
> How many of such fixes would we need to make all the net/ tests
> clean from similar issues?

I noticed it reading the script, then reproduced it on 6.8.0-138-generic.
This Ubuntu kernel ships with CONFIG_NET_FOU=m by default. Without the fou
module loaded, tunnel creation fails with "RTNETLINK answers: Invalid 
argument"
and the test reports a false failure at 0/100 packets. After applying 
the patch
the subtest skips cleanly.

For FOU this was the only gap. The two other net/ tests that use it
(pmtu.sh, rtnetlink.sh) already load the module.

v2 sent: drop Fixes tag and the in‑script comment as requested. Thanks 
for the review.

Regards,
Qingshuang Fu

On Thu, 17 Sep 2026 11:33:09 +0800 Qingshuang Fu wrote:
> >> +if modprobe -q fou; then
> >> +	setup_ipv4
> >> +	run_ping_test -4 eoudp4 "$TUN4_R" "FOU/GRETAP IPv4 multicast encap resubmit"
> >> +else
> >> +	log_test_skip "FOU/GRETAP IPv4 multicast encap resubmit"
> >> +fi  
> > 
> > Two very important questions you must answer before posting v2 or any
> > other similar fix:
> > 
> > Have you actually run into this or it's a result of an LLM scan?
> > 
> > How many of such fixes would we need to make all the net/ tests
> > clean from similar issues?  
> 
> I noticed it reading the script, then reproduced it on 6.8.0-138-generic.
> This Ubuntu kernel ships with CONFIG_NET_FOU=m by default. Without the fou
> module loaded, tunnel creation fails with "RTNETLINK answers: Invalid 
> argument"
> and the test reports a false failure at 0/100 packets. After applying 
> the patch
> the subtest skips cleanly.
> 
> For FOU this was the only gap. The two other net/ tests that use it
> (pmtu.sh, rtnetlink.sh) already load the module.

I did not ask about FOU

> v2 sent: drop Fixes tag and the in‑script comment as requested. Thanks 
> for the review.

I guess I wasn't clear enough. When I say "before posting v2" 
I was hoping you'd give me a chance to respond too :/

Whatever.

在 2026/9/18 06:24, Jakub Kicinski 写道:

> 
> I did not ask about FOU

Apologies, I completely misread the scope.

I've now done a systematic check across tools/testing/selftests/net/.
FOU is the only relevant module lacking any auto-load mechanism
in these tests:

All other tunnel/encap modules (bareudp, vxlan, geneve, gre, ip_gre,
ip6_gre, amt, ifb, xfrm, l2tp) have proper module aliases and can be
auto-loaded via netlink or rtnetlink requests.

In contrast, the fou module has no MODULE_ALIAS_GENL_FAMILY, no
rtnl link alias, and no net-pf-proto alias, so it never auto-loads.

Among the three selftests using FOU, pmtu.sh and rtnetlink.sh already
load the module explicitly, while fou_mcast_encap.sh is the only missing
case.

A naive grep for "encap|tunnel" across the net selftests returns 23
scripts, all of which rely on auto-loading and require no fixes.

> 
> I guess I wasn't clear enough. When I say "before posting v2"
> I was hoping you'd give me a chance to respond too :/
> 
Noted, and sorry for jumping the gun. Won't happen again.