From: Gang Yan <yangang@kylinos.cn>

After an MPTCP connection is established, the sk_sndbuf of client's msk
can be updated through 'subflow_finish_connect'. However, the newly
accepted msk on the server side has a small sk_sndbuf than
msk->first->sk_sndbuf:

'''
MPTCP: msk:00000000e55b09db, msk->sndbuf:20480, msk->first->sndbuf:2626560
'''

This means that when the server immediately sends MSG_DONTWAIT data to
the client after the connection is established, it is more likely to
encounter EAGAIN.

This patch synchronizes the sk_sndbuf by triggering its update during accept.

Fixes: 8005184fd1ca ("mptcp: refactor sndbuf auto-tuning")
Signed-off-by: Gang Yan <yangang@kylinos.cn>
---
Notes:

Hi, Matt,

I'm not sure the commit in 'Fix' tag is correct.

The 3a236aef280e (mptcp: refactor passive socket initialization) removes the
'propagate_sndbuf' in '__mptcp_finish_join' and 'mptcp_stream_accept'.
And the 8005184fd1ca adds it in '__mptcp_finish_join' but not in accept
time. So I think there exists a miss in 8005184fd1ca.

Can you help me to check the 'Fix' tag?

Thanks,
Gang
---
 net/mptcp/protocol.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index e484c6391b48..33610d638385 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -4213,6 +4213,7 @@ static int mptcp_stream_accept(struct socket *sock, struct socket *newsock,
 
 		mptcp_graft_subflows(newsk);
 		mptcp_rps_record_subflows(msk);
+		__mptcp_propagate_sndbuf(newsk, subflow->tcp_sock);
 
 		/* Do late cleanup for the first subflow as necessary. Also
 		 * deal with bad peers not doing a complete shutdown.
-- 
2.43.0

Hi Gang,

Thanks for this patch.

On Thu, 2025-11-27 at 15:04 +0800, Gang Yan wrote:
> From: Gang Yan <yangang@kylinos.cn>
> 
> After an MPTCP connection is established, the sk_sndbuf of client's
> msk
> can be updated through 'subflow_finish_connect'. However, the newly
> accepted msk on the server side has a small sk_sndbuf than
> msk->first->sk_sndbuf:
> 
> '''
> MPTCP: msk:00000000e55b09db, msk->sndbuf:20480, msk->first-
> >sndbuf:2626560
> '''
> 
> This means that when the server immediately sends MSG_DONTWAIT data
> to
> the client after the connection is established, it is more likely to
> encounter EAGAIN.
> 
> This patch synchronizes the sk_sndbuf by triggering its update during
> accept.
> 
> Fixes: 8005184fd1ca ("mptcp: refactor sndbuf auto-tuning")
> Signed-off-by: Gang Yan <yangang@kylinos.cn>
> ---
> Notes:
> 
> Hi, Matt,
> 
> I'm not sure the commit in 'Fix' tag is correct.
> 
> The 3a236aef280e (mptcp: refactor passive socket initialization)
> removes the
> 'propagate_sndbuf' in '__mptcp_finish_join' and
> 'mptcp_stream_accept'.
> And the 8005184fd1ca adds it in '__mptcp_finish_join' but not in
> accept
> time. So I think there exists a miss in 8005184fd1ca.
> 
> Can you help me to check the 'Fix' tag?
> 
> Thanks,
> Gang
> ---
>  net/mptcp/protocol.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
> index e484c6391b48..33610d638385 100644
> --- a/net/mptcp/protocol.c
> +++ b/net/mptcp/protocol.c
> @@ -4213,6 +4213,7 @@ static int mptcp_stream_accept(struct socket
> *sock, struct socket *newsock,
>  
>  		mptcp_graft_subflows(newsk);
>  		mptcp_rps_record_subflows(msk);
> +		__mptcp_propagate_sndbuf(newsk, subflow->tcp_sock);

We generally avoid directly using subflow->tcp_sock and instead use
mptcp_subflow_tcp_sock() helper. What do you think about using this
helper here?

Thanks,
-Geliang

>  
>  		/* Do late cleanup for the first subflow as
> necessary. Also
>  		 * deal with bad peers not doing a complete
> shutdown.

Hi Gang,

Thank you for your modifications, that's great!

Our CI did some validations and here is its report:

- KVM Validation: normal (except selftest_mptcp_join): Success! ✅
- KVM Validation: normal (only selftest_mptcp_join): Success! ✅
- KVM Validation: debug (except selftest_mptcp_join): Success! ✅
- KVM Validation: debug (only selftest_mptcp_join): Success! ✅
- KVM Validation: btf-normal (only bpftest_all): Success! ✅
- KVM Validation: btf-debug (only bpftest_all): Success! ✅
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/19728335198

Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/e6e537dee960
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=1028131


If there are some issues, you can reproduce them using the same environment as
the one used by the CI thanks to a docker image, e.g.:

    $ cd [kernel source code]
    $ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
        --pull always mptcp/mptcp-upstream-virtme-docker:latest \
        auto-normal

For more details:

    https://github.com/multipath-tcp/mptcp-upstream-virtme-docker


Please note that despite all the efforts that have been already done to have a
stable tests suite when executed on a public CI like here, it is possible some
reported issues are not due to your modifications. Still, do not hesitate to
help us improve that ;-)

Cheers,
MPTCP GH Action bot
Bot operated by Matthieu Baerts (NGI0 Core)