summaryrefslogtreecommitdiff
path: root/net/mptcp/pm.c
diff options
context:
space:
mode:
authorPaolo Abeni <pabeni@redhat.com>2022-05-18 15:04:43 -0700
committerJakub Kicinski <kuba@kernel.org>2022-05-19 20:05:07 -0700
commit7b16871f9932d8a371488d2967b033387870a747 (patch)
treea73694f2b3e93e1ee118947a810145744f889a48 /net/mptcp/pm.c
parent9ad084d666194c20a30e3589cbfaf971dae55c24 (diff)
mptcp: stop using the mptcp_has_another_subflow() helper
The mentioned helper requires the msk socket lock, and the current callers don't own it nor can't acquire it, so the access is racy. All the current callers are really checking for infinite mapping fallback, and the latter condition is explicitly tracked by the relevant msk variable: we can safely remove the caller usage - and the caller itself. The issue is present since MP_FAIL implementation, but the fix only applies since the infinite fallback support, ence the somewhat unexpected fixes tag. Fixes: 0530020a7c8f ("mptcp: track and update contiguous data status") Acked-and-tested-by: Geliang Tang <geliang.tang@suse.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'net/mptcp/pm.c')
-rw-r--r--net/mptcp/pm.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/net/mptcp/pm.c b/net/mptcp/pm.c
index 59fdab2d0c27..8ba51120f35b 100644
--- a/net/mptcp/pm.c
+++ b/net/mptcp/pm.c
@@ -303,7 +303,7 @@ void mptcp_pm_mp_fail_received(struct sock *sk, u64 fail_seq)
pr_debug("fail_seq=%llu", fail_seq);
- if (mptcp_has_another_subflow(sk) || !READ_ONCE(msk->allow_infinite_fallback))
+ if (!READ_ONCE(msk->allow_infinite_fallback))
return;
if (!READ_ONCE(subflow->mp_fail_response_expect)) {