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>
---
 net/mptcp/protocol.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index e484c6391b48..72d263148b21 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, mptcp_subflow_tcp_sock(subflow));
 
 		/* Do late cleanup for the first subflow as necessary. Also
 		 * deal with bad peers not doing a complete shutdown.
-- 
2.43.0

On 11/28/25 10:44 AM, 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
> '''

How do you observe the above exactly? subflow-level rcvbuf increases -
in tcp_new_space() -  are propagated to the msk via:

ssk->sk_write_space -> subflow_write_space -> mptcp_propagate_sndbuf.

> 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.

It's unclear to me how the subflow rcvbuf can be greater than default
before sending any data.

/P

> On Fri, Nov 28, 2025 at 03:53:54PM +0100, Paolo Abeni wrote:
> On 11/28/25 10:44 AM, Gang Yan wrote:
> > From: Gang Yan <yangang@kylinos.cn>
> >
Hi Paoto,
So glad to receive your messages.

> > 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
> > '''
> 
> How do you observe the above exactly? subflow-level rcvbuf increases -
I observe this through an normal test, using server to send MSG DONTWAIT messages
to the client once the connection is established.
In fact, we can use the 'send_recv_data'’in mptcp's bpfselftest with
MSG DONTWAIT flag.

> in tcp_new_space() -  are propagated to the msk via:
> 
> ssk->sk_write_space -> subflow_write_space -> mptcp_propagate_sndbuf.
>
Yes, but the 'tcp_sndbuf_extend' also called in 'tcp_init_buffer_space'
immediately after connection enters established state. The client side is updated
via: "subflow_finish_connect' -> 'mptcp propagate_state'. But the server side 
seems need to update msk->sk_sndbuf too. 
> > 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.
> 
> It's unclear to me how the subflow rcvbuf can be greater than default
> before sending any data.
I raised an issue in multpath-tcp/mptcp-net-next, and post some information here,
maybe it is helpful;
https://github.com/multipath-tcp/mptcp_net-next/1ssues/602

Thanks
Gang
> 
> /P
> 
> 

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): Unstable: 1 failed test(s): selftest_simult_flows 🔴
- 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/19760550380

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


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)