Re: [PATCH bpf-next v4 5/6] selftests/bpf: add icmp_send_unreach kfunc IPv6 tests

[sashiko-bot@kernel.org]

Sashiko AI review found 1 potential issue(s):
- [Medium] Hardcoded little-endian value for IPv6 address comparison causes test failure on big-endian architectures.
--

commit 27121b4497956027b4ace73b50126b8070a214c3
Author: Mahe Tardy <mahe.tardy@gmail.com>

selftests/bpf: add icmp_send_unreach kfunc IPv6 tests

This commit extends the existing IPv4 icmp_send_unreach kfunc tests to
support IPv6.

> diff --git a/tools/testing/selftests/bpf/progs/icmp_send_unreach.c b/tools/testing/selftests/bpf/progs/icmp_send_unreach.c
> index 6fc5595f08aa9..112b9cbfab6fe 100644
> --- a/tools/testing/selftests/bpf/progs/icmp_send_unreach.c
> +++ b/tools/testing/selftests/bpf/progs/icmp_send_unreach.c
> @@ -6,6 +6,11 @@
>  #define SERVER_PORT 54321
>  /* 127.0.0.1 in network byte order */
>  #define SERVER_IP 0x7F000001
> +/* ::1 in network byte order */
> +#define SERVER_IP6_0 0x00000000
> +#define SERVER_IP6_1 0x00000000
> +#define SERVER_IP6_2 0x00000000
> +#define SERVER_IP6_3 0x01000000

Does this hardcoded value assume a little-endian architecture?

Since the IPv6 loopback address ::1 in network byte order ends with 0x01,
reading the last 4 bytes as a 32-bit integer yields 0x01000000 on
little-endian systems, but 0x00000001 on big-endian systems like s390x.

> @@ -16,17 +21,46 @@ int egress(struct __sk_buff *skb)
[ ... ]
> +		if (ip6h->daddr.in6_u.u6_addr32[0] != SERVER_IP6_0 ||
> +		    ip6h->daddr.in6_u.u6_addr32[1] != SERVER_IP6_1 ||
> +		    ip6h->daddr.in6_u.u6_addr32[2] != SERVER_IP6_2 ||
> +		    ip6h->daddr.in6_u.u6_addr32[3] != SERVER_IP6_3)
> +			return SK_PASS;

Will this comparison fail on big-endian systems, causing the BPF program to
erroneously ignore the loopback packets?

Could we use bpf_htonl(1) or similar here instead, so the test passes
regardless of the host's endianness?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260420105816.72168-1-mahe.tardy@gmail.com?part=5