Skip to content

Commit 280d654

Browse files
matttbekuba-moo
authored andcommitted
mptcp: avoid dup SUB_CLOSED events after disconnect
In case of subflow disconnect(), which can also happen with the first subflow in case of errors like timeout or reset, mptcp_subflow_ctx_reset will reset most fields from the mptcp_subflow_context structure, including close_event_done. Then, when another subflow is closed, yet another SUB_CLOSED event for the disconnected initial subflow is sent. Because of the previous reset, there are no source address and destination port. A solution is then to also check the subflow's local id: it shouldn't be negative anyway. Another solution would be not to reset subflow->close_event_done at disconnect time, but when reused. But then, probably the whole reset could be done when being reused. Let's not change this logic, similar to TCP with tcp_disconnect(). Fixes: d82809b ("mptcp: avoid duplicated SUB_CLOSED events") Cc: stable@vger.kernel.org Reported-by: Marco Angaroni <marco.angaroni@italtel.com> Closes: multipath-tcp/mptcp_net-next#603 Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260127-net-mptcp-dup-nl-events-v1-1-7f71e1bc4feb@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
1 parent 95f82b2 commit 280d654

1 file changed

Lines changed: 2 additions & 2 deletions

File tree

net/mptcp/protocol.c

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -2598,8 +2598,8 @@ void mptcp_close_ssk(struct sock *sk, struct sock *ssk,
25982598
struct mptcp_sock *msk = mptcp_sk(sk);
25992599
struct sk_buff *skb;
26002600

2601-
/* The first subflow can already be closed and still in the list */
2602-
if (subflow->close_event_done)
2601+
/* The first subflow can already be closed or disconnected */
2602+
if (subflow->close_event_done || READ_ONCE(subflow->local_id) < 0)
26032603
return;
26042604

26052605
subflow->close_event_done = true;

0 commit comments

Comments
 (0)