[PATCH mptcp-net] mptcp: sync the msk->sndbuf at accept() time

[PATCH mptcp-net] mptcp: sync the msk->sndbuf at accept() time

[Gang Yan]

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

Re: [PATCH mptcp-net] mptcp: sync the msk->sndbuf at accept() time

[MPTCP CI]

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)

Re: [PATCH mptcp-net] mptcp: sync the msk->sndbuf at accept() time

[Geliang Tang]

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.

[PATCH mptcp-net] mptcp: sync the msk->sndbuf at accept() time

[Gang Yan]

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

Re: [PATCH mptcp-net] mptcp: sync the msk->sndbuf at accept() time

[MPTCP CI]

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)

Re: [PATCH mptcp-net] mptcp: sync the msk->sndbuf at accept() time

[Paolo Abeni]

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

Re: [PATCH mptcp-net] mptcp: sync the msk->sndbuf at accept() time

[GangYan]

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