* [PATCH mptcp-net] mptcp: fix extra_subflows leak on failed passive join
@ 2026-06-30 9:54 Chenguang Zhao
2026-06-30 10:47 ` Matthieu Baerts
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Chenguang Zhao @ 2026-06-30 9:54 UTC (permalink / raw)
To: mptcp; +Cc: Chenguang Zhao
From: Chenguang Zhao <zhaochenguang@kylinos.cn>
mptcp_pm_allow_new_subflow() increments extra_subflows
before __mptcp_finish_join() on the passive MP_JOIN path.
On synchronous join failure the subflow is dropped without
calling mptcp_close_ssk(), so the counter is not rolled back.
Call mptcp_pm_close_subflow() when the join completion fails.
Signed-off-by: Chenguang Zhao <zhaochenguang@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 cb9515f505aa..b32f0cd262a7 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -3907,6 +3907,7 @@ bool mptcp_finish_join(struct sock *ssk)
mptcp_data_unlock(parent);
if (!ret) {
+ mptcp_pm_close_subflow(msk);
err_prohibited:
subflow->reset_reason = MPTCP_RST_EPROHIBIT;
return false;
--
2.25.1
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH mptcp-net] mptcp: fix extra_subflows leak on failed passive join
2026-06-30 9:54 [PATCH mptcp-net] mptcp: fix extra_subflows leak on failed passive join Chenguang Zhao
@ 2026-06-30 10:47 ` Matthieu Baerts
2026-07-03 9:37 ` Chenguang Zhao
2026-06-30 11:22 ` MPTCP CI
2026-07-01 3:20 ` [PATCH mptcp-net v2] " Chenguang Zhao
2 siblings, 1 reply; 8+ messages in thread
From: Matthieu Baerts @ 2026-06-30 10:47 UTC (permalink / raw)
To: Chenguang Zhao; +Cc: mptcp, Chenguang Zhao
Hi Chenguang,
Thank you for the fix.
> mptcp_pm_allow_new_subflow() increments extra_subflows
> before __mptcp_finish_join() on the passive MP_JOIN path.
I see that this code path is currently not exercised by our test suite:
https://ci-results.mptcp.dev/lcov/export/mptcp/protocol.c.gcov.html#L4031
How did you spot the issue? Do you have a reproducer? Or was it by
reading the code? Assisted by a tool (in this case, please add the
Assisted-by tag)?
I see we have a test for sync connect failure, but not sync join. Do you
mind adding a new Packetdrill test please? Similar to simult_connect.pkt
I suppose:
https://github.com/multipath-tcp/packetdrill/blob/mptcp-net-next/gtests/net/mptcp/syscalls/simult_connect.pkt
> On synchronous join failure the subflow is dropped without
> calling mptcp_close_ssk(), so the counter is not rolled back.
>
> Call mptcp_pm_close_subflow() when the join completion fails.
A fix patch should always have a Fixes tag. Here, I guess it should be:
Fixes: 10f6d46c943d ("mptcp: fix race between MP_JOIN and close")
Apart from that, the modification looks good to me:
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
--
Matthieu Baerts (NGI0) <matttbe@kernel.org>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH mptcp-net] mptcp: fix extra_subflows leak on failed passive join
2026-06-30 9:54 [PATCH mptcp-net] mptcp: fix extra_subflows leak on failed passive join Chenguang Zhao
2026-06-30 10:47 ` Matthieu Baerts
@ 2026-06-30 11:22 ` MPTCP CI
2026-07-01 3:20 ` [PATCH mptcp-net v2] " Chenguang Zhao
2 siblings, 0 replies; 8+ messages in thread
From: MPTCP CI @ 2026-06-30 11:22 UTC (permalink / raw)
To: Chenguang Zhao; +Cc: mptcp
Hi Chenguang,
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/28438179349
Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/654ae3cf6532
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=1118853
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] 8+ messages in thread
* [PATCH mptcp-net v2] mptcp: fix extra_subflows leak on failed passive join
2026-06-30 9:54 [PATCH mptcp-net] mptcp: fix extra_subflows leak on failed passive join Chenguang Zhao
2026-06-30 10:47 ` Matthieu Baerts
2026-06-30 11:22 ` MPTCP CI
@ 2026-07-01 3:20 ` Chenguang Zhao
2026-07-01 4:17 ` MPTCP CI
2026-07-01 6:32 ` Geliang Tang
2 siblings, 2 replies; 8+ messages in thread
From: Chenguang Zhao @ 2026-07-01 3:20 UTC (permalink / raw)
To: mptcp; +Cc: Chenguang Zhao, Matthieu Baerts
From: Chenguang Zhao <zhaochenguang@kylinos.cn>
mptcp_pm_allow_new_subflow() increments extra_subflows
before __mptcp_finish_join() on the passive MP_JOIN path.
On synchronous join failure the subflow is dropped without
calling mptcp_close_ssk(), so the counter is not rolled back.
Call mptcp_pm_close_subflow() when the join completion fails.
Fixes: 3e5014909b56 ("mptcp: cleanup MPJ subflow list handling")
Signed-off-by: Chenguang Zhao <zhaochenguang@kylinos.cn>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
v2:
Hi Matthieu,
Thanks for the review.
- I spotted this by reading the code. I don't have a reproducer
yet. I also see we already have a Packetdrill test for
synchronous connect failure (simult_connect.pkt), but not for
synchronous join failure. I'll add a similar Packetdrill test
for that case and send it in a follow-up patch.
- Add Fixes and Reviewd-by tag.
- I looked again at the history, and I think the Fixes tag
should point to 3e5014909b56 ("mptcp: cleanup MPJ subflow list
handling"), not 10f6d46c943d ("mptcp: fix race between MP_JOIN and close").
v1:
- https://lore.kernel.org/all/20260630095432.1340629-1-chenguang.zhao@linux.dev/
net/mptcp/protocol.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index cb9515f505aa..b32f0cd262a7 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -3907,6 +3907,7 @@ bool mptcp_finish_join(struct sock *ssk)
mptcp_data_unlock(parent);
if (!ret) {
+ mptcp_pm_close_subflow(msk);
err_prohibited:
subflow->reset_reason = MPTCP_RST_EPROHIBIT;
return false;
--
2.25.1
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH mptcp-net v2] mptcp: fix extra_subflows leak on failed passive join
2026-07-01 3:20 ` [PATCH mptcp-net v2] " Chenguang Zhao
@ 2026-07-01 4:17 ` MPTCP CI
2026-07-01 6:32 ` Geliang Tang
1 sibling, 0 replies; 8+ messages in thread
From: MPTCP CI @ 2026-07-01 4:17 UTC (permalink / raw)
To: Chenguang Zhao; +Cc: mptcp
Hi Chenguang,
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/28491654012
Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/4d3b1813957d
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=1119370
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] 8+ messages in thread
* Re: [PATCH mptcp-net v2] mptcp: fix extra_subflows leak on failed passive join
2026-07-01 3:20 ` [PATCH mptcp-net v2] " Chenguang Zhao
2026-07-01 4:17 ` MPTCP CI
@ 2026-07-01 6:32 ` Geliang Tang
2026-07-06 15:07 ` Matthieu Baerts
1 sibling, 1 reply; 8+ messages in thread
From: Geliang Tang @ 2026-07-01 6:32 UTC (permalink / raw)
To: Chenguang Zhao, mptcp; +Cc: Chenguang Zhao, Matthieu Baerts
Hi Chenguang,
Thanks for this v2. However, if there are no code changes, there is no
need to send a v2; we can just reply to the email thread on v1 to
discuss it.
On Wed, 2026-07-01 at 11:20 +0800, Chenguang Zhao wrote:
> From: Chenguang Zhao <zhaochenguang@kylinos.cn>
>
> mptcp_pm_allow_new_subflow() increments extra_subflows
> before __mptcp_finish_join() on the passive MP_JOIN path.
> On synchronous join failure the subflow is dropped without
> calling mptcp_close_ssk(), so the counter is not rolled back.
>
> Call mptcp_pm_close_subflow() when the join completion fails.
>
> Fixes: 3e5014909b56 ("mptcp: cleanup MPJ subflow list handling")
> Signed-off-by: Chenguang Zhao <zhaochenguang@kylinos.cn>
> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
> ---
> v2:
> Hi Matthieu,
> Thanks for the review.
> - I spotted this by reading the code. I don't have a reproducer
> yet. I also see we already have a Packetdrill test for
> synchronous connect failure (simult_connect.pkt), but not for
> synchronous join failure. I'll add a similar Packetdrill test
> for that case and send it in a follow-up patch.
> - Add Fixes and Reviewd-by tag.
> - I looked again at the history, and I think the Fixes tag
> should point to 3e5014909b56 ("mptcp: cleanup MPJ subflow list
> handling"), not 10f6d46c943d ("mptcp: fix race between MP_JOIN and
> close").
The Fixes tag is incorrect and should be 10f6d46c943d ("mptcp: fix race
between MP_JOIN and close"), because that commit introduced the call to
mptcp_pm_allow_new_subflow. There is no need to send a v3, as this can
be updated when applying.
I have changed the status of v2 to "Queued" and v1 to "Superseded".
Thanks,
-Geliang
> v1:
> -
> https://lore.kernel.org/all/20260630095432.1340629-1-chenguang.zhao@linux.dev/
>
> net/mptcp/protocol.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
> index cb9515f505aa..b32f0cd262a7 100644
> --- a/net/mptcp/protocol.c
> +++ b/net/mptcp/protocol.c
> @@ -3907,6 +3907,7 @@ bool mptcp_finish_join(struct sock *ssk)
> mptcp_data_unlock(parent);
>
> if (!ret) {
> + mptcp_pm_close_subflow(msk);
> err_prohibited:
> subflow->reset_reason = MPTCP_RST_EPROHIBIT;
> return false;
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH mptcp-net] mptcp: fix extra_subflows leak on failed passive join
2026-06-30 10:47 ` Matthieu Baerts
@ 2026-07-03 9:37 ` Chenguang Zhao
0 siblings, 0 replies; 8+ messages in thread
From: Chenguang Zhao @ 2026-07-03 9:37 UTC (permalink / raw)
To: Matthieu Baerts; +Cc: mptcp, Chenguang Zhao
Hi Matthieu,
Regarding the sync join failure, I have already submitted a PR.
https://github.com/multipath-tcp/packetdrill/pull/200
Thanks
在 2026/6/30 18:47, Matthieu Baerts 写道:
> Hi Chenguang,
>
> Thank you for the fix.
>
>> mptcp_pm_allow_new_subflow() increments extra_subflows
>> before __mptcp_finish_join() on the passive MP_JOIN path.
> I see that this code path is currently not exercised by our test suite:
>
> https://ci-results.mptcp.dev/lcov/export/mptcp/protocol.c.gcov.html#L4031
>
> How did you spot the issue? Do you have a reproducer? Or was it by
> reading the code? Assisted by a tool (in this case, please add the
> Assisted-by tag)?
>
> I see we have a test for sync connect failure, but not sync join. Do you
> mind adding a new Packetdrill test please? Similar to simult_connect.pkt
> I suppose:
>
> https://github.com/multipath-tcp/packetdrill/blob/mptcp-net-next/gtests/net/mptcp/syscalls/simult_connect.pkt
>
>> On synchronous join failure the subflow is dropped without
>> calling mptcp_close_ssk(), so the counter is not rolled back.
>>
>> Call mptcp_pm_close_subflow() when the join completion fails.
> A fix patch should always have a Fixes tag. Here, I guess it should be:
>
> Fixes: 10f6d46c943d ("mptcp: fix race between MP_JOIN and close")
>
> Apart from that, the modification looks good to me:
>
> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH mptcp-net v2] mptcp: fix extra_subflows leak on failed passive join
2026-07-01 6:32 ` Geliang Tang
@ 2026-07-06 15:07 ` Matthieu Baerts
0 siblings, 0 replies; 8+ messages in thread
From: Matthieu Baerts @ 2026-07-06 15:07 UTC (permalink / raw)
To: Geliang Tang, Chenguang Zhao, mptcp; +Cc: Chenguang Zhao
Hi Geliang, Chenguang,
On 01/07/2026 08:32, Geliang Tang wrote:
> Hi Chenguang,
>
> Thanks for this v2. However, if there are no code changes, there is no
> need to send a v2; we can just reply to the email thread on v1 to
> discuss it.
Indeed. Also, it is easier if you start a new thread with a link to the
previous version, than replying to a previous version.
> On Wed, 2026-07-01 at 11:20 +0800, Chenguang Zhao wrote:
>> From: Chenguang Zhao <zhaochenguang@kylinos.cn>
>>
>> mptcp_pm_allow_new_subflow() increments extra_subflows
>> before __mptcp_finish_join() on the passive MP_JOIN path.
>> On synchronous join failure the subflow is dropped without
>> calling mptcp_close_ssk(), so the counter is not rolled back.
What do you mean by saying "On synchronous join failure"? When I look at
the packetdrill test, we are not talking about synchronous MP_JOIN (SYN
+ MP_JOIN packets in both directions), right?
>> Call mptcp_pm_close_subflow() when the join completion fails.
>>
>> Fixes: 3e5014909b56 ("mptcp: cleanup MPJ subflow list handling")
>> Signed-off-by: Chenguang Zhao <zhaochenguang@kylinos.cn>
>> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
>> ---
>> v2:
>> Hi Matthieu,
>> Thanks for the review.
>> - I spotted this by reading the code. I don't have a reproducer
>> yet. I also see we already have a Packetdrill test for
>> synchronous connect failure (simult_connect.pkt), but not for
>> synchronous join failure. I'll add a similar Packetdrill test
>> for that case and send it in a follow-up patch.
>> - Add Fixes and Reviewd-by tag.
>> - I looked again at the history, and I think the Fixes tag
>> should point to 3e5014909b56 ("mptcp: cleanup MPJ subflow list
>> handling"), not 10f6d46c943d ("mptcp: fix race between MP_JOIN and
>> close").
>
> The Fixes tag is incorrect and should be 10f6d46c943d ("mptcp: fix race
> between MP_JOIN and close"), because that commit introduced the call to
> mptcp_pm_allow_new_subflow. There is no need to send a v3, as this can
> be updated when applying.
+1
> I have changed the status of v2 to "Queued" and v1 to "Superseded".
I will wait to get the packetdrill test ready before applying this patch.
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2026-07-06 15:07 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-30 9:54 [PATCH mptcp-net] mptcp: fix extra_subflows leak on failed passive join Chenguang Zhao
2026-06-30 10:47 ` Matthieu Baerts
2026-07-03 9:37 ` Chenguang Zhao
2026-06-30 11:22 ` MPTCP CI
2026-07-01 3:20 ` [PATCH mptcp-net v2] " Chenguang Zhao
2026-07-01 4:17 ` MPTCP CI
2026-07-01 6:32 ` Geliang Tang
2026-07-06 15:07 ` Matthieu Baerts
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.