mptcp_setsockopt_all_sf() was missing a call to sockopt_seq_inc(). This
is required not to cause missing synchronization for newer subflows
created later on.
This helper is called each time a socket option is set on subflows, and
future ones will need to inherit this option after their creation.
Fixes: 51c5fd09e1b4 ("mptcp: add TCP_MAXSEG sockopt support")
Suggested-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
net/mptcp/sockopt.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c
index 79db15903e7a..30b45d2ab38c 100644
--- a/net/mptcp/sockopt.c
+++ b/net/mptcp/sockopt.c
@@ -812,6 +812,10 @@ static int mptcp_setsockopt_all_sf(struct mptcp_sock *msk, int level,
if (ret)
break;
}
+
+ if (!ret)
+ sockopt_seq_inc(msk);
+
return ret;
}
---
base-commit: 2b52586ab2905a2e2546a2fcd28448c86677306d
change-id: 20260424-mptcp-pm-sockopt-set-all-sf-d14c92924e71
Best regards,
--
Matthieu Baerts (NGI0) <matttbe@kernel.org>
On Fri, 24 Apr 2026, Matthieu Baerts (NGI0) wrote:
> mptcp_setsockopt_all_sf() was missing a call to sockopt_seq_inc(). This
> is required not to cause missing synchronization for newer subflows
> created later on.
>
> This helper is called each time a socket option is set on subflows, and
> future ones will need to inherit this option after their creation.
>
> Fixes: 51c5fd09e1b4 ("mptcp: add TCP_MAXSEG sockopt support")
> Suggested-by: Paolo Abeni <pabeni@redhat.com>
> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
> ---
> net/mptcp/sockopt.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c
> index 79db15903e7a..30b45d2ab38c 100644
> --- a/net/mptcp/sockopt.c
> +++ b/net/mptcp/sockopt.c
> @@ -812,6 +812,10 @@ static int mptcp_setsockopt_all_sf(struct mptcp_sock *msk, int level,
> if (ret)
> break;
> }
> +
> + if (!ret)
> + sockopt_seq_inc(msk);
> +
This only appears to be used for TCP_MAXSEG, and the limits checked for
that sockopt are the same for every TCP socket - so there's currently no
risk of having the setting applied to some subflows but not others and
skipping the increment here seems like the right thing to do.
Not sure if that's true for all possible socket options!
Reviewed-by: Mat Martineau <martineau@kernel.org>
> return ret;
> }
>
>
> ---
> base-commit: 2b52586ab2905a2e2546a2fcd28448c86677306d
> change-id: 20260424-mptcp-pm-sockopt-set-all-sf-d14c92924e71
>
> Best regards,
> --
> Matthieu Baerts (NGI0) <matttbe@kernel.org>
>
>
>
Hi Mat,
On 29/04/2026 02:26, Mat Martineau wrote:
> On Fri, 24 Apr 2026, Matthieu Baerts (NGI0) wrote:
>
>> mptcp_setsockopt_all_sf() was missing a call to sockopt_seq_inc(). This
>> is required not to cause missing synchronization for newer subflows
>> created later on.
>>
>> This helper is called each time a socket option is set on subflows, and
>> future ones will need to inherit this option after their creation.
>>
>> Fixes: 51c5fd09e1b4 ("mptcp: add TCP_MAXSEG sockopt support")
>> Suggested-by: Paolo Abeni <pabeni@redhat.com>
>> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
>> ---
>> net/mptcp/sockopt.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c
>> index 79db15903e7a..30b45d2ab38c 100644
>> --- a/net/mptcp/sockopt.c
>> +++ b/net/mptcp/sockopt.c
>> @@ -812,6 +812,10 @@ static int mptcp_setsockopt_all_sf(struct
>> mptcp_sock *msk, int level,
>> if (ret)
>> break;
>> }
>> +
>> + if (!ret)
>> + sockopt_seq_inc(msk);
>> +
>
> This only appears to be used for TCP_MAXSEG, and the limits checked for
> that sockopt are the same for every TCP socket - so there's currently no
> risk of having the setting applied to some subflows but not others and
> skipping the increment here seems like the right thing to do.
>
> Not sure if that's true for all possible socket options!
Thank you for the review! Indeed, it is safe for the moment for this option.
Maybe the value could be copied, but on the other hand, I don't know if
we need to prevent that: if the buffer is written concurrently when
calling setsockopt with TCP, that's a strange behaviour from the
userspace, and the end-result will depend on when the kernel reads the
value...
Anyway, no need to worry about that now! :)
New patches for t/upstream-net and t/upstream:
- bbfb75da3b4f: mptcp: sockopt: increase seq in mptcp_setsockopt_all_sf
- Results: 8b78db730d79..581441b9adeb (export-net)
- Results: 3455e15b8193..d1636d717db9 (export)
Tests are now in progress:
- export-net:
https://github.com/multipath-tcp/mptcp_net-next/commit/008c005a9ad82212f63b7f9afd0aa01417d53b38/checks
- export:
https://github.com/multipath-tcp/mptcp_net-next/commit/2f2a495d6dd05fffde5489f73dfd318f66c5d5a8/checks
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
Hi Matthieu,
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_userspace_pm ⚠️
- KVM Validation: normal (only selftest_mptcp_join): Success! ✅
- KVM Validation: debug (except selftest_mptcp_join): Unstable: 1 failed test(s): packetdrill_dss ⚠️
- 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/24909569350
Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/e2f27c46b96f
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=1085341
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)
© 2016 - 2026 Red Hat, Inc.