Users reported a scenario where MPTCP connections that were configured
with SO_KEEPALIVE prior to connect would fail to enable their keepalives
if MTPCP fell back to TCP mode.
After investigating, this affects keepalives for any connection where
sync_socket_options is called on a socket that is in the closed or
listening state. Joins are handled properly. For connects,
sync_socket_options is called when the socket is still in the closed
state. The tcp_set_keepalive() function does not act on sockets that
are closed or listening, hence keepalive is not immediately enabled.
Since the SO_KEEPOPEN flag is absent, it is not enabled later in the
connect sequence via tcp_finish_connect. Setting the keepalive via
sockopt after connect does work, but would not address any subsequently
created flows.
Fortunately, the fix here is straight-forward: set SOCK_KEEPOPEN on the
subflow when calling sync_socket_options.
The fix was valdidated both by using tcpdump to observe keeplaive
packets not being sent before the fix, and being sent after the fix. It
was also possible to observe via ss that the keepalive timer was not
enabled on these sockets before the fix, but was enabled afterwards.
Fixes: 1b3e7ede1365 ("mptcp: setsockopt: handle SO_KEEPALIVE and SO_PRIORITY")
Cc: stable@vger.kernel.org
Signed-off-by: Krister Johansen <kjlx@templeofstupid.com>
---
net/mptcp/sockopt.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c
index 2c267aff95be..13108e9f982b 100644
--- a/net/mptcp/sockopt.c
+++ b/net/mptcp/sockopt.c
@@ -1532,13 +1532,11 @@ static void sync_socket_options(struct mptcp_sock *msk, struct sock *ssk)
{
static const unsigned int tx_rx_locks = SOCK_RCVBUF_LOCK | SOCK_SNDBUF_LOCK;
struct sock *sk = (struct sock *)msk;
+ int kaval = !!sock_flag(sk, SOCK_KEEPOPEN);
- if (ssk->sk_prot->keepalive) {
- if (sock_flag(sk, SOCK_KEEPOPEN))
- ssk->sk_prot->keepalive(ssk, 1);
- else
- ssk->sk_prot->keepalive(ssk, 0);
- }
+ if (ssk->sk_prot->keepalive)
+ ssk->sk_prot->keepalive(ssk, kaval);
+ sock_valbool_flag(ssk, SOCK_KEEPOPEN, kaval);
ssk->sk_priority = sk->sk_priority;
ssk->sk_bound_dev_if = sk->sk_bound_dev_if;
base-commit: 319f7385f22c85618235ab0169b80092fa3c7696
--
2.43.0
Hi Krister, On 06/09/2025 02:43, Krister Johansen wrote: > Users reported a scenario where MPTCP connections that were configured > with SO_KEEPALIVE prior to connect would fail to enable their keepalives > if MTPCP fell back to TCP mode. > > After investigating, this affects keepalives for any connection where > sync_socket_options is called on a socket that is in the closed or > listening state. Joins are handled properly. For connects, > sync_socket_options is called when the socket is still in the closed > state. The tcp_set_keepalive() function does not act on sockets that > are closed or listening, hence keepalive is not immediately enabled. > Since the SO_KEEPOPEN flag is absent, it is not enabled later in the > connect sequence via tcp_finish_connect. Setting the keepalive via > sockopt after connect does work, but would not address any subsequently > created flows. > > Fortunately, the fix here is straight-forward: set SOCK_KEEPOPEN on the > subflow when calling sync_socket_options. > > The fix was valdidated both by using tcpdump to observe keeplaive > packets not being sent before the fix, and being sent after the fix. It > was also possible to observe via ss that the keepalive timer was not > enabled on these sockets before the fix, but was enabled afterwards. Thank you for the fix! Indeed, the SOCK_KEEPOPEN flag was missing! This patch looks good to me as well: Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> @Netdev Maintainers: please apply this patch in 'net' directly. But I can always re-send it later if preferred. Cheers, Matt -- Sponsored by the NGI0 Core fund.
Hi Matt, On Sat, 2025-09-06 at 15:26 +0200, Matthieu Baerts wrote: > Hi Krister, > > On 06/09/2025 02:43, Krister Johansen wrote: > > Users reported a scenario where MPTCP connections that were > > configured > > with SO_KEEPALIVE prior to connect would fail to enable their > > keepalives > > if MTPCP fell back to TCP mode. > > > > After investigating, this affects keepalives for any connection > > where > > sync_socket_options is called on a socket that is in the closed or > > listening state. Joins are handled properly. For connects, > > sync_socket_options is called when the socket is still in the > > closed > > state. The tcp_set_keepalive() function does not act on sockets > > that > > are closed or listening, hence keepalive is not immediately > > enabled. > > Since the SO_KEEPOPEN flag is absent, it is not enabled later in > > the > > connect sequence via tcp_finish_connect. Setting the keepalive via > > sockopt after connect does work, but would not address any > > subsequently > > created flows. > > > > Fortunately, the fix here is straight-forward: set SOCK_KEEPOPEN on > > the > > subflow when calling sync_socket_options. > > > > The fix was valdidated both by using tcpdump to observe keeplaive > > packets not being sent before the fix, and being sent after the > > fix. It > > was also possible to observe via ss that the keepalive timer was > > not > > enabled on these sockets before the fix, but was enabled > > afterwards. > > > Thank you for the fix! Indeed, the SOCK_KEEPOPEN flag was missing! > This > patch looks good to me as well: > > Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> > > > @Netdev Maintainers: please apply this patch in 'net' directly. But I > can always re-send it later if preferred. nit: I just noticed his patch breaks 'Reverse X-Mas Tree' order in sync_socket_options(). If you think any changes are needed, please update this when you re-send it. Thanks, -Geliang > > Cheers, > Matt
Hi Krister, Thank you for your modifications, that's great! Our CI did some validations and here is its report: - KVM Validation: normal: Unstable: 1 failed test(s): selftest_mptcp_connect 🔴 - KVM Validation: debug: 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/17507741030 Initiator: Patchew Applier Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/b682ae8c4184 Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=999551 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)
Hi Krister, On Fri, 2025-09-05 at 17:43 -0700, Krister Johansen wrote: > Users reported a scenario where MPTCP connections that were > configured > with SO_KEEPALIVE prior to connect would fail to enable their > keepalives > if MTPCP fell back to TCP mode. > > After investigating, this affects keepalives for any connection where > sync_socket_options is called on a socket that is in the closed or > listening state. Joins are handled properly. For connects, > sync_socket_options is called when the socket is still in the closed > state. The tcp_set_keepalive() function does not act on sockets that > are closed or listening, hence keepalive is not immediately enabled. > Since the SO_KEEPOPEN flag is absent, it is not enabled later in the > connect sequence via tcp_finish_connect. Setting the keepalive via > sockopt after connect does work, but would not address any > subsequently > created flows. > > Fortunately, the fix here is straight-forward: set SOCK_KEEPOPEN on > the > subflow when calling sync_socket_options. > > The fix was valdidated both by using tcpdump to observe keeplaive > packets not being sent before the fix, and being sent after the fix. > It > was also possible to observe via ss that the keepalive timer was not > enabled on these sockets before the fix, but was enabled afterwards. > > Fixes: 1b3e7ede1365 ("mptcp: setsockopt: handle SO_KEEPALIVE and > SO_PRIORITY") > Cc: stable@vger.kernel.org > Signed-off-by: Krister Johansen <kjlx@templeofstupid.com> Thanks for this fix. Good catch! Reviewed-by: Geliang Tang <geliang@kernel.org> -Geliang > --- > net/mptcp/sockopt.c | 10 ++++------ > 1 file changed, 4 insertions(+), 6 deletions(-) > > diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c > index 2c267aff95be..13108e9f982b 100644 > --- a/net/mptcp/sockopt.c > +++ b/net/mptcp/sockopt.c > @@ -1532,13 +1532,11 @@ static void sync_socket_options(struct > mptcp_sock *msk, struct sock *ssk) > { > static const unsigned int tx_rx_locks = SOCK_RCVBUF_LOCK | > SOCK_SNDBUF_LOCK; > struct sock *sk = (struct sock *)msk; > + int kaval = !!sock_flag(sk, SOCK_KEEPOPEN); > > - if (ssk->sk_prot->keepalive) { > - if (sock_flag(sk, SOCK_KEEPOPEN)) > - ssk->sk_prot->keepalive(ssk, 1); > - else > - ssk->sk_prot->keepalive(ssk, 0); > - } > + if (ssk->sk_prot->keepalive) > + ssk->sk_prot->keepalive(ssk, kaval); > + sock_valbool_flag(ssk, SOCK_KEEPOPEN, kaval); > > ssk->sk_priority = sk->sk_priority; > ssk->sk_bound_dev_if = sk->sk_bound_dev_if; > > base-commit: 319f7385f22c85618235ab0169b80092fa3c7696
© 2016 - 2025 Red Hat, Inc.