Re: [PATCH mptcp-next] selftests: mptcp: sockopt: test passive Fast Open early write push

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] selftests: mptcp: Fast Open test falls back to 3WHS due to missing TFO cookie
- [Medium] selftests/mptcp: Fast Open tests fail CI on older kernels missing support
--

commit b13d72847e34610069932e37b3730c9df5c74745
Author: T S Rameshkumar <rameshsv06@gmail.com>

selftests: mptcp: sockopt: test passive Fast Open early write push

This commit adds automated test coverage for passive Fast Open early write
data push in MPTCP. The server enables TCP_FASTOPEN on an MPTCP listening
socket, and the client connects using TCP_FASTOPEN_CONNECT.

> diff --git a/tools/testing/selftests/net/mptcp/mptcp_sockopt.c b/tools/testing/selftests/net/mptcp/mptcp_sockopt.c
> index d68515b7903b8..861de909abbd8 100644
> --- a/tools/testing/selftests/net/mptcp/mptcp_sockopt.c
> +++ b/tools/testing/selftests/net/mptcp/mptcp_sockopt.c

[ ... ]

> @@ -254,6 +255,14 @@ static int sock_connect_mptcp(const char * const remoteaddr,
>  		if (sock < 0)
>  			continue;
>  
> +		if (do_tfo) {
> +			int one = 1;
> +
> +			if (setsockopt(sock, IPPROTO_TCP, TCP_FASTOPEN_CONNECT,
> +				       &one, sizeof(one)) < 0)
> +				die_perror("setsockopt TCP_FASTOPEN_CONNECT");
> +		}
> +

[Severity: Medium]
Since MPTCP Fast Open was introduced in Linux 6.1+, will unconditionally
calling setsockopt() cause CI failures on older LTS kernels?

On older kernels, setsockopt() returns -EOPNOTSUPP. By using die_perror(),
the test terminates with a hard failure instead of gracefully skipping.

Could this be updated to catch EOPNOTSUPP and exit with a designated SKIP
code?

>  		if (connect(sock, a->ai_addr, a->ai_addrlen) == 0)
>  			break; /* success */
>  

[ ... ]

> @@ -726,13 +738,36 @@ static int server(int pipefd)
>  		break;
>  	}
>  
> +	if (do_tfo) {
> +		int qlen = 5;
> +
> +		if (setsockopt(fd, IPPROTO_TCP, TCP_FASTOPEN, &qlen, sizeof(qlen)) < 0)
> +			die_perror("setsockopt TCP_FASTOPEN");
> +	}
> +

[Severity: Medium]
Similarly, will this cause CI failures on older kernels without MPTCP
Fast Open support?

A failure here returns -EOPNOTSUPP, but die_perror() will cause a hard
failure instead of gracefully bypassing the test.

>  	r = write(pipefd, "conn", 4);
>  	assert(r == 4);
>  

[ ... ]

> diff --git a/tools/testing/selftests/net/mptcp/mptcp_sockopt.sh b/tools/testing/selftests/net/mptcp/mptcp_sockopt.sh
> index b4e3eddc9cf21..e88a8bbeb6e36 100755
> --- a/tools/testing/selftests/net/mptcp/mptcp_sockopt.sh
> +++ b/tools/testing/selftests/net/mptcp/mptcp_sockopt.sh

[ ... ]

> @@ -359,6 +359,39 @@ do_tcpinq_tests()
>  	return $?
>  }
>  
> +do_fastopen_tests()
> +{
> +	local lret=0
> +
> +	ip netns exec "$ns_sbox" sysctl -q net.ipv4.tcp_fastopen=3
> +
> +	ip netns exec "$ns_sbox" ./mptcp_sockopt -f
> +	lret=$?
> +

[Severity: Medium]
Will this sequence actually exercise the Fast Open early write feature?

Configuring net.ipv4.tcp_fastopen=3 requires a valid TFO cookie to accept
data within the initial SYN packet. Because the script executes
./mptcp_sockopt -f exactly once per address family, the client has an empty
cookie cache.

When connect() is called with TCP_FASTOPEN_CONNECT without a cookie, the
kernel falls back to a normal blocking 3-way handshake that requests a
cookie but sends no data in the SYN packet. The server's accept() will
block until the 3-way handshake finishes, bypassing the TFO early write
(TCP_SYN_RECV) state entirely.

Could the test be executed twice (first to get the cookie, second to use it)
or should tcp_fastopen be configured to allow cookieless Fast Open (e.g.,
adding TFO_SERVER_COOKIE_NOT_REQD)?

> +	print_title "Fast Open early write v4"
> +	if [ $lret -ne 0 ]; then
> +		mptcp_lib_pr_fail
> +		mptcp_lib_result_fail "Fast Open early write v4"
> +		ret=$lret
> +		return
> +	fi
> +	mptcp_lib_pr_ok
> +	mptcp_lib_result_pass "Fast Open early write v4"
> +

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261008111003.136143-1-rameshkumar.t@phytecembedded.in?part=1