From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A315534FF50; Wed, 3 Dec 2025 16:13:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764778394; cv=none; b=trWhI9Kt+9url9wSsLLaoSxod4kd3I+7odExwZQyAfDvMUC0TV8pnkCJ+H6KnV6dQR43ei4Emf2+HlJQhOCxrzNMKzn9YfrJXyILppAIPzTbhFFntZU8GaqOjmdM78+/bY++fcV2vyqwHJHBz5uE+aTFr4DZzMVJGmjD8XR69kg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764778394; c=relaxed/simple; bh=HJST/VmlUYdgnVZv2XnmCjaEvJuDCwxDTA6B1ZG2Q3w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=D3fU5Resis8Jss2IZTO8vCmpgTsdz4QUiluJGDr1FsASX+PVODvamlTek7VPkIZZNfdYOU4yLt0cJkAXPZx5sRsjmdoVDFsMhU9cTMmv+FrnoIENfnzqk+zZ/iSNb1QgTgvEKfLutdBjN7XbDdu8cZVHJV4jq8Td4WFJMOXVJ+M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=pk3EOwYL; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="pk3EOwYL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 25DFCC4CEF5; Wed, 3 Dec 2025 16:13:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1764778394; bh=HJST/VmlUYdgnVZv2XnmCjaEvJuDCwxDTA6B1ZG2Q3w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pk3EOwYL3vCNRq3HPh1dWmCXv4Ggl2hIoW/y8QWp+WQb7kahou0wBbMWdoaaWqHCw 6Kb8JF03vMmbf4m1miJ7XKmxqbhZmWZ1tov2ByXS1yPmCiLmzvv6/RiRRjLEZkEYHJ aJJkwADQGS6ajzCp2a1q/HLF2XVOdgfGcQGBt4RQ= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Paolo Abeni , "Matthieu Baerts (NGI0)" , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.15 332/392] mptcp: fix premature close in case of fallback Date: Wed, 3 Dec 2025 16:28:02 +0100 Message-ID: <20251203152426.386125108@linuxfoundation.org> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20251203152414.082328008@linuxfoundation.org> References: <20251203152414.082328008@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 5.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Paolo Abeni [ Upstream commit 17393fa7b7086664be519e7230cb6ed7ec7d9462 ] I'm observing very frequent self-tests failures in case of fallback when running on a CONFIG_PREEMPT kernel. The root cause is that subflow_sched_work_if_closed() closes any subflow as soon as it is half-closed and has no incoming data pending. That works well for regular subflows - MPTCP needs bi-directional connectivity to operate on a given subflow - but for fallback socket is race prone. When TCP peer closes the connection before the MPTCP one, subflow_sched_work_if_closed() will schedule the MPTCP worker to gracefully close the subflow, and shortly after will do another schedule to inject and process a dummy incoming DATA_FIN. On CONFIG_PREEMPT kernel, the MPTCP worker can kick-in and close the fallback subflow before subflow_sched_work_if_closed() is able to create the dummy DATA_FIN, unexpectedly interrupting the transfer. Address the issue explicitly avoiding closing fallback subflows on when the peer is only half-closed. Note that, when the subflow is able to create the DATA_FIN before the worker invocation, the worker will change the msk state before trying to close the subflow and will skip the latter operation as the msk will not match anymore the precondition in __mptcp_close_subflow(). Fixes: f09b0ad55a11 ("mptcp: close subflow when receiving TCP+FIN") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20251118-net-mptcp-misc-fixes-6-18-rc6-v1-3-806d3781c95f@kernel.org Signed-off-by: Jakub Kicinski [ sk -> ssk ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- net/mptcp/protocol.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -2411,7 +2411,8 @@ static void __mptcp_close_subflow(struct if (ssk_state != TCP_CLOSE && (ssk_state != TCP_CLOSE_WAIT || - inet_sk_state_load((struct sock *)ssk) != TCP_ESTABLISHED)) + inet_sk_state_load((struct sock *)ssk) != TCP_ESTABLISHED || + __mptcp_check_fallback(msk))) continue; /* 'subflow_data_ready' will re-sched once rx queue is empty */