Re: [PATCH mptcp-net 2/2] Squash-to: "mptcp: do not reschedule the RTX timer for fallback sockets"

[Paolo Abeni <pabeni@redhat.com>]

On 8/26/26 12:30 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Non-blocking MPTCP Fastopen bypasses `mptcp_connect`, leaving the socket permanently in `TCP_CLOSE` and failing to enable the RTX timer.
> --
> 
> commit 4679eada053d3ad7385facbcb9d12c98ccd146f2
> Author: Paolo Abeni <pabeni@redhat.com>
> Subject: Squash-to: "mptcp: do not reschedule the RTX timer for fallback sockets"
> 
> This commit replaces the MPTCP_RTX_DISABLED flag with MPTCP_RTX_ENABLED to
> explicitly control the retransmit timer status across the socket lifecycle.
> It sets the enabled flag during active connect and passive initialization.
> 
>> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
>> index 2f17c5daa704e..a28a0506d28da 100644
>> --- a/net/mptcp/protocol.c
>> +++ b/net/mptcp/protocol.c
> 
> [ ... ]
> 
>> @@ -4154,6 +4155,7 @@ static int mptcp_connect(struct sock *sk, struct sockaddr_unsized *uaddr,
>>  		return PTR_ERR(ssk);
>>  
>>  	mptcp_set_state(sk, TCP_SYN_SENT);
>> +	set_bit(MPTCP_RTX_ENABLED, &msk->flags);
> 
> [Severity: High]
> Does this change leave the RTX timer disabled during non-blocking Fastopen
> connections?

Funny, opus-4.8 locally had the same concern and discarded it as
hallucination. Unfortunately I don't have the log handy.

> 
> When a non-blocking TCP Fast Open connection is initiated on an MPTCP socket
> (using MSG_FASTOPEN and MSG_DONTWAIT), mptcp_sendmsg_fastopen() skips the call
> to __inet_stream_connect(), which bypasses mptcp_connect() entirely:

It looks real, I'll send a v2.

/P