From nobody Wed Apr 30 04:59:15 2025
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 84363265604;
Mon, 24 Feb 2025 18:19:32 +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=1740421172; cv=none;
b=Q0bSqvAFiLkr2mcyyp/fzFypjq61OEFm7zccHEi7YR6382zOXOD0k35TP9m6np+C6HtzB2geb6NB4e+l8zfn/g6zn+15M85DzKagjZqSiQwL2XZ5hQpN2n71C9gYczcDY+KitoDzrQsg27uy/OzNvNXd1gZ90Ye2Fgmrv6koELM=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1740421172; c=relaxed/simple;
bh=Ik5KcxOdBM/F5vV5+lATgGZEb3Liw9RgUd8HTlpzH+I=;
h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References:
In-Reply-To:To:Cc;
b=PwzOpq05JCKP4T9jLXjbpqqtJkoG9Tgq25fdEao8zxO6bmTLXEMvZegZSDE/2jsQI09QZBghmYu3nzf5/Ad6v+ESn3jUZHjne+43nxrDTPDiZKMO3trI1h+6sQ/aRDqyoEJ6QtYIu2x3vYoNq8MN11w1qll1k0kR2THgn648g7c=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org
header.b=oXnGv36l; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org
header.b="oXnGv36l"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 74C39C4CEED;
Mon, 24 Feb 2025 18:19:22 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
s=k20201202; t=1740421171;
bh=Ik5KcxOdBM/F5vV5+lATgGZEb3Liw9RgUd8HTlpzH+I=;
h=From:Date:Subject:References:In-Reply-To:To:Cc:From;
b=oXnGv36lyUdZtvzS5T6CvDOf+ZSRONp17h0ULPV5LZdOMEjsVe4/rN6ebQTR1z5ox
WOxyVGq4eUO/IPkKZ9UX94z5A8clIhqP/4Owj0seCIpX79xIoXDdebrWdZCeQgkbC/
sKadh77rzUyn2emDwRDD7oh8BiEiRTgEvv/mE+PBnEIsgf+KPytTrqIEjNeWv9W4io
XLw+Uscg8gkF1u3DgtK9wdNNmLlEQDo8MfqJCDMdWMy3a8u7/rmxgp2RxfD7ZdFV/2
vghu7ZYlW6n6BohcaVdfrNtrGQ7Q242SU5vGxsSmPSseRFYz8LpR4Zee6Cx7dGk8n4
/DF6wEwC/JKYQ==
From: "Matthieu Baerts (NGI0)" <matttbe@kernel.org>
Date: Mon, 24 Feb 2025 19:11:50 +0100
Subject: [PATCH net 1/3] mptcp: always handle address removal under msk
socket lock
Precedence: bulk
X-Mailing-List: mptcp@lists.linux.dev
List-Id: <mptcp.lists.linux.dev>
List-Subscribe: <mailto:mptcp+subscribe@lists.linux.dev>
List-Unsubscribe: <mailto:mptcp+unsubscribe@lists.linux.dev>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <20250224-net-mptcp-misc-fixes-v1-1-f550f636b435@kernel.org>
References: <20250224-net-mptcp-misc-fixes-v1-0-f550f636b435@kernel.org>
In-Reply-To: <20250224-net-mptcp-misc-fixes-v1-0-f550f636b435@kernel.org>
To: mptcp@lists.linux.dev, Mat Martineau <martineau@kernel.org>,
Geliang Tang <geliang@kernel.org>, "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
"Matthieu Baerts (NGI0)" <matttbe@kernel.org>, stable@vger.kernel.org,
syzbot+cd3ce3d03a3393ae9700@syzkaller.appspotmail.com
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=openpgp-sha256; l=5378; i=matttbe@kernel.org;
h=from:subject:message-id; bh=N617GDa06HVkbv2TZdEF1e4KCUtp3l7035G9g1HRT6k=;
b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBnvLbEvP9GGFr4OTtuOCxi+i1GNlUL8cQgsQadh
iim8VvpNKmJAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZ7y2xAAKCRD2t4JPQmmg
cz32D/9AnAVVcnkjSHPoYQvzU9djHZa7masy7+qU0gDbqhb+r7ARABvOz69M5Vs3JZC0oVWQUU7
8xX//JDuAdNeERJANUBwKKgjGB3z1cCCyHN7piE4odMEyAEiksvNLa1X6Z0MHilFslB60hkmnw3
MbG2QFjE48t0fX3uvpzHcragMEnfdp6CB4OA7ZFDAvjYrspzKNMqvWpzlsLHNhe43LgQtzlO2kC
cLih87IMCw3B2PXHteV25wougqaSfBPhNqSGZ6u7Hr+dGHm2SxDxB1fW2xihww9qc2aSn9a/vjH
TFbYWaQeaBdILl32fY9iQNYpFTNSutRufWmKqLI1/JBaS6/sfmpcRTvNvYgWG6QSBFMJnjkXANd
1ODa/xBH5Vf8JJbHlXIGCPGElin9ATxG4rkqc5Khu7Z84VE9fBqhsQVCsuyolCz9cIsEn/DMlWB
OvKkF3ZUBul6nMlbhr3Nu9TylX7tgGDX30tMWhYZ9PzC1F0QfR1PuAn/aRgGVX4sVlWcJKVXGId
V8QG7rB6rBwQqDJxIQ4pWz4p8WHrPSMY0Fuik+NwDQ3sqm9Xuxu5FTscIzgwyD/d1zgHPulPtTg
be0Jt8IWzxadghCj9qOhV73BjyUGa258E3K5EWrQsCMRfk/qG6VE3E9o1maiYJ/BWjJu2rmiDfJ
s+NbCu+ylg9N/+g==
X-Developer-Key: i=matttbe@kernel.org; a=openpgp;
fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073
From: Paolo Abeni <pabeni@redhat.com>
Syzkaller reported a lockdep splat in the PM control path:
WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 sock_owned_by_me i=
nclude/net/sock.h:1711 [inline]
WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 msk_owned_by_me ne=
t/mptcp/protocol.h:363 [inline]
WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 mptcp_pm_nl_addr_s=
end_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788
Modules linked in:
CPU: 0 UID: 0 PID: 6693 Comm: syz.0.205 Not tainted 6.14.0-rc2-syzkaller-=
00303-gad1b832bf1cf #0
Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 1=
2/27/2024
RIP: 0010:sock_owned_by_me include/net/sock.h:1711 [inline]
RIP: 0010:msk_owned_by_me net/mptcp/protocol.h:363 [inline]
RIP: 0010:mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788
Code: 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ca 7b d3 f5 eb b9 e=
8 c3 7b d3 f5 90 0f 0b 90 e9 dd fb ff ff e8 b5 7b d3 f5 90 <0f> 0b 90 e9 3e=
fb ff ff 44 89 f1 80 e1 07 38 c1 0f 8c eb fb ff ff
RSP: 0000:ffffc900034f6f60 EFLAGS: 00010283
RAX: ffffffff8bee3c2b RBX: 0000000000000001 RCX: 0000000000080000
RDX: ffffc90004d42000 RSI: 000000000000a407 RDI: 000000000000a408
RBP: ffffc900034f7030 R08: ffffffff8bee37f6 R09: 0100000000000000
R10: dffffc0000000000 R11: ffffed100bcc62e4 R12: ffff88805e6316e0
R13: ffff88805e630c00 R14: dffffc0000000000 R15: ffff88805e630c00
FS: 00007f7e9a7e96c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000=
000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2fd18ff8 CR3: 0000000032c24000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
mptcp_pm_remove_addr+0x103/0x1d0 net/mptcp/pm.c:59
mptcp_pm_remove_anno_addr+0x1f4/0x2f0 net/mptcp/pm_netlink.c:1486
mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_netlink.c:1518 [inl=
ine]
mptcp_pm_nl_del_addr_doit+0x118d/0x1af0 net/mptcp/pm_netlink.c:1629
genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline]
genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]
genl_rcv_msg+0xb1f/0xec0 net/netlink/genetlink.c:1210
netlink_rcv_skb+0x206/0x480 net/netlink/af_netlink.c:2543
genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219
netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline]
netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1348
netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1892
sock_sendmsg_nosec net/socket.c:718 [inline]
__sock_sendmsg+0x221/0x270 net/socket.c:733
____sys_sendmsg+0x53a/0x860 net/socket.c:2573
___sys_sendmsg net/socket.c:2627 [inline]
__sys_sendmsg+0x269/0x350 net/socket.c:2659
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f7e9998cde9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f=
7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff=
ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f7e9a7e9038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f7e99ba5fa0 RCX: 00007f7e9998cde9
RDX: 000000002000c094 RSI: 0000400000000000 RDI: 0000000000000007
RBP: 00007f7e99a0e2a0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007f7e99ba5fa0 R15: 00007fff49231088
Indeed the PM can try to send a RM_ADDR over a msk without acquiring
first the msk socket lock.
The bugged code-path comes from an early optimization: when there
are no subflows, the PM should (usually) not send RM_ADDR
notifications.
The above statement is incorrect, as without locks another process
could concurrent create a new subflow and cause the RM_ADDR generation.
Additionally the supposed optimization is not very effective even
performance-wise, as most mptcp sockets should have at least one
subflow: the MPC one.
Address the issue removing the buggy code path, the existing "slow-path"
will handle correctly even the edge case.
Fixes: b6c08380860b ("mptcp: remove addr and subflow in PM netlink")
Cc: stable@vger.kernel.org
Reported-by: syzbot+cd3ce3d03a3393ae9700@syzkaller.appspotmail.com
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/546
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
net/mptcp/pm_netlink.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/net/mptcp/pm_netlink.c b/net/mptcp/pm_netlink.c
index 572d160edca33c0a941203d8ae0b0bde0f2ef3e2..c0e47f4f7b1aa2fedf615c44ea5=
95c1f9d2528f9 100644
--- a/net/mptcp/pm_netlink.c
+++ b/net/mptcp/pm_netlink.c
@@ -1514,11 +1514,6 @@ static int mptcp_nl_remove_subflow_and_signal_addr(s=
truct net *net,
if (mptcp_pm_is_userspace(msk))
goto next;
=20
- if (list_empty(&msk->conn_list)) {
- mptcp_pm_remove_anno_addr(msk, addr, false);
- goto next;
- }
-
lock_sock(sk);
remove_subflow =3D mptcp_lookup_subflow_by_saddr(&msk->conn_list, addr);
mptcp_pm_remove_anno_addr(msk, addr, remove_subflow &&
--=20
2.47.1
From nobody Wed Apr 30 04:59:15 2025
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 7FCD5265637;
Mon, 24 Feb 2025 18:19:38 +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=1740421178; cv=none;
b=ZWWgYI+dSFt8DCcLslzzREfojLw244TocEBXFAr/MFe3FXz8NVUKLAN9TSb10RJhy8KD3404PHJExj1jv8CZVypdQj36sxFbgM2qw/kZCaMvNx20FSC/NduyBaUdUaBeGj2fDsh7PWMkN0j5E9tgqxcCRUhIo1/rqLmkxSCFQLI=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1740421178; c=relaxed/simple;
bh=1piqEsg8TREgMWofEyn4jJ96CEYOxAF1p1P8q05XkLs=;
h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References:
In-Reply-To:To:Cc;
b=fRdkB+411vf7xuD9WduqOfLvLV5jityj5XC4/jeKwD9w/8jBsKzIw4cPszrVmjrItC+pS5vqj33u9Aov2MsSr+OIWVbNlom/6wgu7cRnjJfd7aTrkdLn0gVhfv2yaUNmYJ07sNBU2hLkV38l+DHhZ6MzCSSeZYoHGUa3EP1f4uA=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org
header.b=KCnUeAAp; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org
header.b="KCnUeAAp"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 963A0C4CED6;
Mon, 24 Feb 2025 18:19:32 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
s=k20201202; t=1740421178;
bh=1piqEsg8TREgMWofEyn4jJ96CEYOxAF1p1P8q05XkLs=;
h=From:Date:Subject:References:In-Reply-To:To:Cc:From;
b=KCnUeAApLkkGko6SP7l7F15fOSW6KYftikbjynwWHDzhpGaS1C5dm+hphcTuhgcvD
6JjpO3g140z/Wflx4pTah+ylqAgeWOm0s99TJW9Cehz+NTcr7MwfHVaeHKae4rm2j+
enwWzEbTGM4hX7PmiPS0r4+cpkbHgtAvo2OXd5b43Q0kQa6IM+pxJMCIPOHoYhYaze
yEko/7XeLOjW1E4YTp6mEuE7w12Ny2Ll3h0zQh6hMk8fRSaPDXfQa4VNX1l5/1WWQ8
kTQtV3BKBLCAhsDpMRSw0e+uiRNp3Jifj8JHmnk8tA1rgLvt6FjJHsjJ3UnWzEByu9
mNf8tTFH8L+dQ==
From: "Matthieu Baerts (NGI0)" <matttbe@kernel.org>
Date: Mon, 24 Feb 2025 19:11:51 +0100
Subject: [PATCH net 2/3] mptcp: reset when MPTCP opts are dropped after
join
Precedence: bulk
X-Mailing-List: mptcp@lists.linux.dev
List-Id: <mptcp.lists.linux.dev>
List-Subscribe: <mailto:mptcp+subscribe@lists.linux.dev>
List-Unsubscribe: <mailto:mptcp+unsubscribe@lists.linux.dev>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <20250224-net-mptcp-misc-fixes-v1-2-f550f636b435@kernel.org>
References: <20250224-net-mptcp-misc-fixes-v1-0-f550f636b435@kernel.org>
In-Reply-To: <20250224-net-mptcp-misc-fixes-v1-0-f550f636b435@kernel.org>
To: mptcp@lists.linux.dev, Mat Martineau <martineau@kernel.org>,
Geliang Tang <geliang@kernel.org>, "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
"Matthieu Baerts (NGI0)" <matttbe@kernel.org>, stable@vger.kernel.org,
"Chester A. Unal" <chester.a.unal@xpedite-tech.com>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=openpgp-sha256; l=3536; i=matttbe@kernel.org;
h=from:subject:message-id; bh=1piqEsg8TREgMWofEyn4jJ96CEYOxAF1p1P8q05XkLs=;
b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBnvLbEVe5ugfNB/pEH8gsCo37OFpAAyoQsRPom1
VoDnLcRVI2JAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZ7y2xAAKCRD2t4JPQmmg
c0VrD/4wezF7LMq2B3x0qP48+OYaeX4LE+vQFlL2AyJudtuOv21VQynOTxViGWTiwukpGqKFe/r
mVsYWPgDK3mSqKvQWZ+S3IirU+Hx6iY0K7D2FEu2hs6KEe6Qc6GYpRxKehY7ga2zfpElSOopwwu
35Mt9GPcac0d0w/9WGZo0nyqee2YC4XQvtSdloya4SnSXwKW9X2A5Gp6FtLRHDGEjxRP8rYyHAr
Naf7zHvZ/+rN3LSPggCmdNRI2xQe+MGaAIoiqBl5h8NiBcBkUD+/M1bDXg+JtSNxt2cexhAXqk2
WvEMZ/tDuJuuQ2CTvJlFo9dk7dTBa6gqzEqpOgHZuFHQffVo9pMSLxoZBhRey96MjY6kz0YwqYx
dud3EOMSLgegP6dMkdWu5ewGqN3pMd2wm8q70MCP31gsJc7JdriABPJDLGz0/NbTq/hsMIao/YN
hMFJcLrDb1Oql8FbjW+LNVkPqzEB6h8XaHBg3AzsvMuXczStGG3oKeDTUap0Al+uP9C3Rq1ibOz
9GPsdqk5H8CSZ0qUSLn5PRLbqLQ4c4HQLKLUZj+WtqHEx7HWat57mmqs/xyj37KxjS/sBtd6pWz
it4xY8KhZeLGnDjOKCv38cjf6VflrtLucU6e+lNl4GGodzwa0N0SHLg6p1KiaLOO0lwtu6PfgAQ
PmbczMT7fJqDjuQ==
X-Developer-Key: i=matttbe@kernel.org; a=openpgp;
fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073
Before this patch, if the checksum was not used, the subflow was only
reset if map_data_len was !=3D 0. If there were no MPTCP options or an
invalid mapping, map_data_len was not set to the data len, and then the
subflow was not reset as it should have been, leaving the MPTCP
connection in a wrong fallback mode.
This map_data_len condition has been introduced to handle the reception
of the infinite mapping. Instead, a new dedicated mapping error could
have been returned and treated as a special case. However, the commit
31bf11de146c ("mptcp: introduce MAPPING_BAD_CSUM") has been introduced
by Paolo Abeni soon after, and backported later on to stable. It better
handle the csum case, and it means the exception for valid_csum_seen in
subflow_can_fallback(), plus this one for the infinite mapping in
subflow_check_data_avail(), are no longer needed.
In other words, the code can be simplified there: a fallback should only
be done if msk->allow_infinite_fallback is set. This boolean is set to
false once MPTCP-specific operations acting on the whole MPTCP
connection vs the initial path have been done, e.g. a second path has
been created, or an MPTCP re-injection -- yes, possible even with a
single subflow. The subflow_can_fallback() helper can then be dropped,
and replaced by this single condition.
This also makes the code clearer: a fallback should only be done if it
is possible to do so.
While at it, no need to set map_data_len to 0 in get_mapping_status()
for the infinite mapping case: it will be set to skb->len just after, at
the end of subflow_check_data_avail(), and not read in between.
Fixes: f8d4bcacff3b ("mptcp: infinite mapping receiving")
Cc: stable@vger.kernel.org
Reported-by: Chester A. Unal <chester.a.unal@xpedite-tech.com>
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/544
Acked-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Tested-by: Chester A. Unal <chester.a.unal@xpedite-tech.com>
---
net/mptcp/subflow.c | 15 +--------------
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index dfcbef9c46246983d21c827d9551d4eb2c95430e..9f18217dddc865bc467a2c5c34a=
a4bf23bf3ac75 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -1142,7 +1142,6 @@ static enum mapping_status get_mapping_status(struct =
sock *ssk,
if (data_len =3D=3D 0) {
pr_debug("infinite mapping received\n");
MPTCP_INC_STATS(sock_net(ssk), MPTCP_MIB_INFINITEMAPRX);
- subflow->map_data_len =3D 0;
return MAPPING_INVALID;
}
=20
@@ -1286,18 +1285,6 @@ static void subflow_sched_work_if_closed(struct mptc=
p_sock *msk, struct sock *ss
mptcp_schedule_work(sk);
}
=20
-static bool subflow_can_fallback(struct mptcp_subflow_context *subflow)
-{
- struct mptcp_sock *msk =3D mptcp_sk(subflow->conn);
-
- if (subflow->mp_join)
- return false;
- else if (READ_ONCE(msk->csum_enabled))
- return !subflow->valid_csum_seen;
- else
- return READ_ONCE(msk->allow_infinite_fallback);
-}
-
static void mptcp_subflow_fail(struct mptcp_sock *msk, struct sock *ssk)
{
struct mptcp_subflow_context *subflow =3D mptcp_subflow_ctx(ssk);
@@ -1393,7 +1380,7 @@ static bool subflow_check_data_avail(struct sock *ssk)
return true;
}
=20
- if (!subflow_can_fallback(subflow) && subflow->map_data_len) {
+ if (!READ_ONCE(msk->allow_infinite_fallback)) {
/* fatal protocol error, close the socket.
* subflow_error_report() will introduce the appropriate barriers
*/
--=20
2.47.1
From nobody Wed Apr 30 04:59:15 2025
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 88BB2265CCB;
Mon, 24 Feb 2025 18:19:45 +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=1740421185; cv=none;
b=qMIK+X8mEXr+sd1QnIZNfzmaYaOWAz5PAsFo3wgle3vnTfK5HCcjymOTe+EgqfpciTwj/tjHcDZiJSULPGy4yPEHUtUi5azKAbyac2FLqNpEFJxGzykfDnOLB7yVeRdgDxbeN9FzDo5KoWPAOm1EG7n2dTFr2dxm8pzhiJdGZ3A=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1740421185; c=relaxed/simple;
bh=aOpTiNZ4UTpq4GD/D/yo0qqX81+gFPuHmfJiBAbK3MQ=;
h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References:
In-Reply-To:To:Cc;
b=srAcSIYf0FpYzLXlfYZWxcs/clAd/+jW37xUwJEotl4PObFR9FLSQm6DSIuxxZoQ2xLbN+68epYlFlZTq4ljtkV3cl97hfT2ezrdffagiSYPIPZFsj7TIqck0VFcEjy+dHzxJCoZ6m+7O6qnQfH08PxEhWK6cEtE9AOeENzXOFU=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org
header.b=rl95B2IT; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org
header.b="rl95B2IT"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 012EEC4CEED;
Mon, 24 Feb 2025 18:19:38 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
s=k20201202; t=1740421185;
bh=aOpTiNZ4UTpq4GD/D/yo0qqX81+gFPuHmfJiBAbK3MQ=;
h=From:Date:Subject:References:In-Reply-To:To:Cc:From;
b=rl95B2ITOHzPPIZEYbmMq41/UD94NPfW+6HKhV8S6qH+goXyzLp9dOGu2tHZj3FIC
izZF6fi3TP8430/x/Rm5Lc7cZJth30EJMGbucf7kxM27mGbXVxTz1ZP7tg+H92//OA
jJuEjT6afOMHY/5Yxh7F3Hckc+MPm6Sn7vtJFHvs6JCSx8UHzP70RzPkNcc3cxJ8Po
qTQ+loH3rAy5CbRToQWS1DRSNhgpbjUHgR+K5tWOTm85uB+c2tYMgri3oHXZGTOOQ6
x6W3fAWZKFnXGZM35Wye89ws3p0XxjwP9xfrSX9Z8hzNsGLTcqVTZrsZv8DbLTW1Kg
j0fjSK3tlQFsw==
From: "Matthieu Baerts (NGI0)" <matttbe@kernel.org>
Date: Mon, 24 Feb 2025 19:11:52 +0100
Subject: [PATCH net 3/3] mptcp: safety check before fallback
Precedence: bulk
X-Mailing-List: mptcp@lists.linux.dev
List-Id: <mptcp.lists.linux.dev>
List-Subscribe: <mailto:mptcp+subscribe@lists.linux.dev>
List-Unsubscribe: <mailto:mptcp+unsubscribe@lists.linux.dev>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <20250224-net-mptcp-misc-fixes-v1-3-f550f636b435@kernel.org>
References: <20250224-net-mptcp-misc-fixes-v1-0-f550f636b435@kernel.org>
In-Reply-To: <20250224-net-mptcp-misc-fixes-v1-0-f550f636b435@kernel.org>
To: mptcp@lists.linux.dev, Mat Martineau <martineau@kernel.org>,
Geliang Tang <geliang@kernel.org>, "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
"Matthieu Baerts (NGI0)" <matttbe@kernel.org>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=openpgp-sha256; l=942; i=matttbe@kernel.org;
h=from:subject:message-id; bh=aOpTiNZ4UTpq4GD/D/yo0qqX81+gFPuHmfJiBAbK3MQ=;
b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBnvLbEGKhlFTAlo0xrvPENFUa8ZD2kU1QWhHNua
ZIEQaX3b6KJAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZ7y2xAAKCRD2t4JPQmmg
c1voD/9cqEQ+1y1c6VouIeNTM7UDiOdfkaJWyXPQTRrmJpYqraTb0kL/QR1sQJ1MpHazbkgsE75
H2NfvDaAP0v+hnSR+5IjZoYRM96/D2aMLuo7BQk3jRmtSWxlZjD6k8OjX8v+AejB4zrpN7tC2TG
vVmxaX1xs+bKLGgPz6ybC5uVfvKIL2wubnUNWMkEVBVdOX76tvPZ4jPEqcN0BHQuts0LzkQ88W7
G26Pbh6ZK3v8/vYBUDARKQ9xA/mnQISWdh336gF3NvTDZOOJyERDdDMSyaVl8wdT9aEepyQp0sa
WkL9ssuTqapCmCMzkzgWyvX5fyGfIj/69taRBrATqgDZM/reZk849ZKXhMB+38SagUdsQYtv0Kv
00cgOXd2ZfReAzWIFHK+aylLY39XJN/UJGeM9vRrBZJr8zOyfgx7tlL0NpVzELkCBEP0licKKv3
GBBcJe3ewG9aDCLWWq6uYmq/EBeyTejWgIdJ08tAAywbc/spUzyXHFOLhBUA9sV/o7w11DwRMUs
UllDm5MYwcc7nSmxj48DwERKeazNryjR4yutkSqUtuP08iB+QXSR12lmFOKDLhoBTcid2Pi+Kp6
6cH5cIEdZiSrMIarf9oQ8bv0HF+Le6bojQEjEFYJ5+VKmZ9jgfNuyucZeqScgBRqV0tkEJLDrF3
MmiGY2zzjTPb8/g==
X-Developer-Key: i=matttbe@kernel.org; a=openpgp;
fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073
Recently, some fallback have been initiated, while the connection was
not supposed to fallback.
Add a safety check with a warning to detect when an wrong attempt to
fallback is being done. This should help detecting any future issues
quicker.
Acked-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
net/mptcp/protocol.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index f6a207958459db5bd39f91ed7431b5a766669f92..ad21925af061263d908bd9faddf=
faef979f46c93 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -1199,6 +1199,8 @@ static inline void __mptcp_do_fallback(struct mptcp_s=
ock *msk)
pr_debug("TCP fallback already done (msk=3D%p)\n", msk);
return;
}
+ if (WARN_ON_ONCE(!READ_ONCE(msk->allow_infinite_fallback)))
+ return;
set_bit(MPTCP_FALLBACK_DONE, &msk->flags);
}
=20
--=20
2.47.1