* [PATCH mptcp-net v3 0/2] mptcp: sync the msk->sndbuf at accept() time
@ 2026-04-07 8:45 Gang Yan
2026-04-07 8:45 ` [PATCH mptcp-net v3 1/2] " Gang Yan
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Gang Yan @ 2026-04-07 8:45 UTC (permalink / raw)
To: mptcp; +Cc: Gang Yan
From: Gang Yan <yangang@kylinos.cn>
Changelog:
v3:
- Add a check in diag.sh to check the sndbuf of the server side.
Gang Yan (2):
mptcp: sync the msk->sndbuf at accept() time
selftests: mptcp: add a check for sndbuf of S/C
net/mptcp/protocol.c | 1 +
tools/testing/selftests/net/mptcp/diag.sh | 26 +++++++++++++++++++++++
2 files changed, 27 insertions(+)
--
2.43.0
^ permalink raw reply [flat|nested] 7+ messages in thread* [PATCH mptcp-net v3 1/2] mptcp: sync the msk->sndbuf at accept() time
2026-04-07 8:45 [PATCH mptcp-net v3 0/2] mptcp: sync the msk->sndbuf at accept() time Gang Yan
@ 2026-04-07 8:45 ` Gang Yan
2026-04-10 9:04 ` Paolo Abeni
2026-04-07 8:45 ` [PATCH mptcp-net v3 2/2] selftests: mptcp: add a check for sndbuf of S/C Gang Yan
2026-04-09 9:57 ` [PATCH mptcp-net v3 0/2] mptcp: sync the msk->sndbuf at accept() time MPTCP CI
2 siblings, 1 reply; 7+ messages in thread
From: Gang Yan @ 2026-04-07 8:45 UTC (permalink / raw)
To: mptcp; +Cc: 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 patch synchronizes the sk_sndbuf by triggering its update during
accept.
Fixes: 8005184fd1ca ("mptcp: refactor sndbuf auto-tuning")
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/602
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 17b9a8c13ebf..6f6c8cabf74f 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -4252,6 +4252,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
^ permalink raw reply related [flat|nested] 7+ messages in thread* Re: [PATCH mptcp-net v3 1/2] mptcp: sync the msk->sndbuf at accept() time
2026-04-07 8:45 ` [PATCH mptcp-net v3 1/2] " Gang Yan
@ 2026-04-10 9:04 ` Paolo Abeni
2026-04-10 9:10 ` Matthieu Baerts
2026-04-11 3:51 ` gang.yan
0 siblings, 2 replies; 7+ messages in thread
From: Paolo Abeni @ 2026-04-10 9:04 UTC (permalink / raw)
To: Gang Yan, mptcp; +Cc: Gang Yan, Matthieu Baerts (NGI0)
On 4/7/26 10:45 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
> '''
>
> This patch synchronizes the sk_sndbuf by triggering its update during
> accept.
I finally could wrap my head around the root cause: tcp_child_process()
-> tcp_init_transfer() -> tcp_sndbuf_expand() can and will grow the ssk
sndbuf _after_ tcp_check_req() -> subflow_syn_recv_sock() ->
mptcp_sk_clone_init() where __mptcp_propagate_sndbuf() is currently hooked.
I think the latter __mptcp_propagate_sndbuf() invocation can be removed,
and the commit message expanded to capture some of the above.
With the above included feel free to add:
Acked-by: Paolo Abeni <pabeni@redhat.com>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH mptcp-net v3 1/2] mptcp: sync the msk->sndbuf at accept() time
2026-04-10 9:04 ` Paolo Abeni
@ 2026-04-10 9:10 ` Matthieu Baerts
2026-04-11 3:51 ` gang.yan
1 sibling, 0 replies; 7+ messages in thread
From: Matthieu Baerts @ 2026-04-10 9:10 UTC (permalink / raw)
To: Paolo Abeni; +Cc: Gang Yan, Gang Yan, mptcp
Hi Paolo,
On 10/04/2026 11:04, Paolo Abeni wrote:
> On 4/7/26 10:45 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
>> '''
>>
>> This patch synchronizes the sk_sndbuf by triggering its update during
>> accept.
>
> I finally could wrap my head around the root cause: tcp_child_process()
> -> tcp_init_transfer() -> tcp_sndbuf_expand() can and will grow the ssk
> sndbuf _after_ tcp_check_req() -> subflow_syn_recv_sock() ->
> mptcp_sk_clone_init() where __mptcp_propagate_sndbuf() is currently hooked.
>
> I think the latter __mptcp_propagate_sndbuf() invocation can be removed,
> and the commit message expanded to capture some of the above.
>
> With the above included feel free to add:
>
> Acked-by: Paolo Abeni <pabeni@redhat.com>
Thank you for this review!
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH mptcp-net v3 1/2] mptcp: sync the msk->sndbuf at accept() time
2026-04-10 9:04 ` Paolo Abeni
2026-04-10 9:10 ` Matthieu Baerts
@ 2026-04-11 3:51 ` gang.yan
1 sibling, 0 replies; 7+ messages in thread
From: gang.yan @ 2026-04-11 3:51 UTC (permalink / raw)
To: Paolo Abeni, mptcp
April 10, 2026 at 5:04 PM, "Paolo Abeni" <pabeni@redhat.com mailto:pabeni@redhat.com?to=%22Paolo%20Abeni%22%20%3Cpabeni%40redhat.com%3E > wrote:
>
> On 4/7/26 10:45 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
> > '''
> >
> > This patch synchronizes the sk_sndbuf by triggering its update during
> > accept.
> >
> I finally could wrap my head around the root cause: tcp_child_process()
> -> tcp_init_transfer() -> tcp_sndbuf_expand() can and will grow the ssk
> sndbuf _after_ tcp_check_req() -> subflow_syn_recv_sock() ->
> mptcp_sk_clone_init() where __mptcp_propagate_sndbuf() is currently hooked.
>
> I think the latter __mptcp_propagate_sndbuf() invocation can be removed,
> and the commit message expanded to capture some of the above.
>
> With the above included feel free to add:
>
> Acked-by: Paolo Abeni <pabeni@redhat.com>
Hi Paolo,
Thanks for your suggestions. The v4 code will be sent soon.
Cherrs,
Gang
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH mptcp-net v3 2/2] selftests: mptcp: add a check for sndbuf of S/C
2026-04-07 8:45 [PATCH mptcp-net v3 0/2] mptcp: sync the msk->sndbuf at accept() time Gang Yan
2026-04-07 8:45 ` [PATCH mptcp-net v3 1/2] " Gang Yan
@ 2026-04-07 8:45 ` Gang Yan
2026-04-09 9:57 ` [PATCH mptcp-net v3 0/2] mptcp: sync the msk->sndbuf at accept() time MPTCP CI
2 siblings, 0 replies; 7+ messages in thread
From: Gang Yan @ 2026-04-07 8:45 UTC (permalink / raw)
To: mptcp; +Cc: Gang Yan
From: Gang Yan <yangang@kylinos.cn>
Add a new chk_sndbuf() helper to diag.sh that extracts the sndbuf (the
'tb' field from 'ss -m' skmem output) for both server and client MPTCP
sockets, and verifies they are equal.
Without the previous patch, it will fails:
'''
05 all listen sockets [ OK ]
06 after MPC handshake [ OK ]
07 ....chk sndbuf server/client [FAIL] server sndbuf=20480 != client sndbuf=2630656
'''
Signed-off-by: Gang Yan <yangang@kylinos.cn>
---
tools/testing/selftests/net/mptcp/diag.sh | 26 +++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/tools/testing/selftests/net/mptcp/diag.sh b/tools/testing/selftests/net/mptcp/diag.sh
index d847ff1737c3..aa01a1dd0bdd 100755
--- a/tools/testing/selftests/net/mptcp/diag.sh
+++ b/tools/testing/selftests/net/mptcp/diag.sh
@@ -322,6 +322,31 @@ wait_connected()
done
}
+chk_sndbuf()
+{
+ local server_sndbuf client_sndbuf msg
+ local port=${1}
+
+ msg="....chk sndbuf server/client"
+ server_sndbuf=$(ss -N "${ns}" -inmHM "sport" "${port}" | grep -oP 'tb\K\d+')
+ client_sndbuf=$(ss -N "${ns}" -inmHM "dport" "${port}" | grep -oP 'tb\K\d+')
+
+ mptcp_lib_print_title "${msg}"
+ if [ -z "${server_sndbuf}" ] || [ -z "${client_sndbuf}" ]; then
+ mptcp_lib_pr_fail "server sndbuf=${server_sndbuf} client sndbuf=${client_sndbuf}"
+ mptcp_lib_result_fail "${msg}"
+ ret=${KSFT_FAIL}
+ elif [ "${server_sndbuf}" != "${client_sndbuf}" ]; then
+ mptcp_lib_pr_fail "server sndbuf=${server_sndbuf} != client sndbuf=${client_sndbuf}"
+ mptcp_lib_result_fail "${msg}"
+ ret=${KSFT_FAIL}
+ else
+ mptcp_lib_pr_ok
+ mptcp_lib_result_pass "${msg}"
+ fi
+}
+
+
trap cleanup EXIT
mptcp_lib_ns_init ns
@@ -341,6 +366,7 @@ echo "b" | \
127.0.0.1 >/dev/null &
wait_connected $ns 10000
chk_msk_nr 2 "after MPC handshake"
+chk_sndbuf 10000
chk_last_time_info 10000
chk_msk_remote_key_nr 2 "....chk remote_key"
chk_msk_fallback_nr 0 "....chk no fallback"
--
2.43.0
^ permalink raw reply related [flat|nested] 7+ messages in thread* Re: [PATCH mptcp-net v3 0/2] mptcp: sync the msk->sndbuf at accept() time
2026-04-07 8:45 [PATCH mptcp-net v3 0/2] mptcp: sync the msk->sndbuf at accept() time Gang Yan
2026-04-07 8:45 ` [PATCH mptcp-net v3 1/2] " Gang Yan
2026-04-07 8:45 ` [PATCH mptcp-net v3 2/2] selftests: mptcp: add a check for sndbuf of S/C Gang Yan
@ 2026-04-09 9:57 ` MPTCP CI
2 siblings, 0 replies; 7+ messages in thread
From: MPTCP CI @ 2026-04-09 9:57 UTC (permalink / raw)
To: Gang Yan; +Cc: mptcp
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): Unstable: 1 failed test(s): packetdrill_sockopts ⚠️
- 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/24181789538
Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/7359a54dfdbd
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=1078012
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)
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2026-04-11 3:51 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-04-07 8:45 [PATCH mptcp-net v3 0/2] mptcp: sync the msk->sndbuf at accept() time Gang Yan
2026-04-07 8:45 ` [PATCH mptcp-net v3 1/2] " Gang Yan
2026-04-10 9:04 ` Paolo Abeni
2026-04-10 9:10 ` Matthieu Baerts
2026-04-11 3:51 ` gang.yan
2026-04-07 8:45 ` [PATCH mptcp-net v3 2/2] selftests: mptcp: add a check for sndbuf of S/C Gang Yan
2026-04-09 9:57 ` [PATCH mptcp-net v3 0/2] mptcp: sync the msk->sndbuf at accept() time MPTCP CI
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.