The SO_LINGER socket option has been supported for a while with MPTCP
sockets [1], but it didn't cause the equivalent of a TCP reset as
expected when enabled and its time was set to 0. This was causing some
behavioural differences with TCP where some connections were not
promptly stopped as expected.

To fix that, an extra condition is checked at close() time before
sending an MP_FASTCLOSE, the MPTCP equivalent of a TCP reset.

Note that backporting up to [1] will be difficult as more changes are
needed to be able to send MP_FASTCLOSE. It seems better to stop at [2],
which was supposed to already imitate TCP.

Validated with MPTCP packetdrill tests [3].

Fixes: 268b12387460 ("mptcp: setsockopt: support SO_LINGER") [1]
Fixes: d21f83485518 ("mptcp: use fastclose on more edge scenarios") [2]
Reported-by: Lance Tuller <lance@lance0.com>
Closes: https://github.com/lance0/xfr/pull/67
Link: https://github.com/multipath-tcp/packetdrill/pull/196 [3]
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
 net/mptcp/protocol.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 6b486fc94c16..0db50e3715c3 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -3302,7 +3302,8 @@ bool __mptcp_close(struct sock *sk, long timeout)
 		goto cleanup;
 	}
 
-	if (mptcp_data_avail(msk) || timeout < 0) {
+	if (mptcp_data_avail(msk) || timeout < 0 ||
+	    (sock_flag(sk, SOCK_LINGER) && !sk->sk_lingertime)) {
 		/* If the msk has read data, or the caller explicitly ask it,
 		 * do the MPTCP equivalent of TCP reset, aka MPTCP fastclose
 		 */

---
base-commit: 3662f0d0a0b4cdc50193718dd64af57d671ebd59
change-id: 20260421-mptcp-fastclose-linger-f041352cd5e5

Best regards,
--  
Matthieu Baerts (NGI0) <matttbe@kernel.org>

On Tue, 21 Apr 2026, Matthieu Baerts (NGI0) wrote:

> The SO_LINGER socket option has been supported for a while with MPTCP
> sockets [1], but it didn't cause the equivalent of a TCP reset as
> expected when enabled and its time was set to 0. This was causing some
> behavioural differences with TCP where some connections were not
> promptly stopped as expected.
>
> To fix that, an extra condition is checked at close() time before
> sending an MP_FASTCLOSE, the MPTCP equivalent of a TCP reset.
>
> Note that backporting up to [1] will be difficult as more changes are
> needed to be able to send MP_FASTCLOSE. It seems better to stop at [2],
> which was supposed to already imitate TCP.
>
> Validated with MPTCP packetdrill tests [3].
>
> Fixes: 268b12387460 ("mptcp: setsockopt: support SO_LINGER") [1]
> Fixes: d21f83485518 ("mptcp: use fastclose on more edge scenarios") [2]
> Reported-by: Lance Tuller <lance@lance0.com>
> Closes: https://github.com/lance0/xfr/pull/67
> Link: https://github.com/multipath-tcp/packetdrill/pull/196 [3]
> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
> ---
> net/mptcp/protocol.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)

LGTM, thanks Matthieu!

Reviewed-by: Mat Martineau <martineau@kernel.org>

>
> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
> index 6b486fc94c16..0db50e3715c3 100644
> --- a/net/mptcp/protocol.c
> +++ b/net/mptcp/protocol.c
> @@ -3302,7 +3302,8 @@ bool __mptcp_close(struct sock *sk, long timeout)
> 		goto cleanup;
> 	}
>
> -	if (mptcp_data_avail(msk) || timeout < 0) {
> +	if (mptcp_data_avail(msk) || timeout < 0 ||
> +	    (sock_flag(sk, SOCK_LINGER) && !sk->sk_lingertime)) {
> 		/* If the msk has read data, or the caller explicitly ask it,
> 		 * do the MPTCP equivalent of TCP reset, aka MPTCP fastclose
> 		 */
>
> ---
> base-commit: 3662f0d0a0b4cdc50193718dd64af57d671ebd59
> change-id: 20260421-mptcp-fastclose-linger-f041352cd5e5
>
> Best regards,
> --
> Matthieu Baerts (NGI0) <matttbe@kernel.org>
>
>
>

Hi Mat,

On 22/04/2026 17:35, Mat Martineau wrote:
> On Tue, 21 Apr 2026, Matthieu Baerts (NGI0) wrote:
> 
>> The SO_LINGER socket option has been supported for a while with MPTCP
>> sockets [1], but it didn't cause the equivalent of a TCP reset as
>> expected when enabled and its time was set to 0. This was causing some
>> behavioural differences with TCP where some connections were not
>> promptly stopped as expected.
>>
>> To fix that, an extra condition is checked at close() time before
>> sending an MP_FASTCLOSE, the MPTCP equivalent of a TCP reset.
>>
>> Note that backporting up to [1] will be difficult as more changes are
>> needed to be able to send MP_FASTCLOSE. It seems better to stop at [2],
>> which was supposed to already imitate TCP.
>>
>> Validated with MPTCP packetdrill tests [3].
>>
>> Fixes: 268b12387460 ("mptcp: setsockopt: support SO_LINGER") [1]
>> Fixes: d21f83485518 ("mptcp: use fastclose on more edge scenarios") [2]
>> Reported-by: Lance Tuller <lance@lance0.com>
>> Closes: https://github.com/lance0/xfr/pull/67
>> Link: https://github.com/multipath-tcp/packetdrill/pull/196 [3]
>> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
>> ---
>> net/mptcp/protocol.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
> 
> LGTM, thanks Matthieu!
Thank you for the review!

Now in our tree:

New patches for t/upstream-net and t/upstream:
- 0f10cdb3e082: mptcp: fastclose msk when linger time is 0
- Results: 292dd6570cfd..102349628b51 (export-net)
- Results: b3fa12c3ddab..67117a5e3e86 (export)

Tests are now in progress:

- export-net:
https://github.com/multipath-tcp/mptcp_net-next/commit/1acee4b422ad7ee72705775b633d8ae8fa75d508/checks
- export:
https://github.com/multipath-tcp/mptcp_net-next/commit/e676a2d67d616900b5d4be83471f12c5d7a1433e/checks

And the packetdrill PR has been merged.

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): Success! ✅
- KVM Validation: normal (only selftest_mptcp_join): Success! ✅
- KVM Validation: debug (except selftest_mptcp_join): Unstable: 3 failed test(s): packetdrill_dss packetdrill_sockopts selftest_diag ⚠️ 
- 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/24731778234

Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/3f24800c45cb
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=1083917


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)