FAILED: patch "[PATCH] mptcp: pm: only decrement add_addr_accepted for MPJ req" failed to apply to 5.10-stable tree

The patch below does not apply to the 5.10-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

To reproduce the conflict and resubmit, you may use the following commands:

git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y
git checkout FETCH_HEAD
git cherry-pick -x 1c1f721375989579e46741f59523e39ec9b2a9bd
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<[email protected]>' --in-reply-to '2024082653-scenic-deprive-65e4@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^..

Possible dependencies:

1c1f72137598 ("mptcp: pm: only decrement add_addr_accepted for MPJ req") 6a09788c1a66 ("mptcp: pm: inc RmAddr MIB counter once per RM_ADDR ID") 3ad14f54bd74 ("mptcp: more accurate MPC endpoint tracking") c157bbe776b7 ("mptcp: allow the in kernel PM to set MPC subflow priority") 843b5e75efff ("mptcp: fix local endpoint accounting") 4638de5aefe5 ("mptcp: handle local addrs announced by userspace PMs") 4d25247d3ae4 ("mptcp: bypass in-kernel PM restrictions for non-kernel PMs") 14b06811bec6 ("mptcp: Bypass kernel PM when userspace PM is enabled") 0530020a7c8f ("mptcp: track and update contiguous data status") 0348c690ed37 ("mptcp: add the fallback check")
1761fed25678 ("mptcp: don't send RST for single subflow") c682bf536cf4 ("mptcp: add pm_nl_pernet helpers")
ae7bd9ccecc3 ("selftests: mptcp: join: option to execute specific tests") e59300ce3ff8 ("selftests: mptcp: join: reset failing links") 3afd0280e7d3 ("selftests: mptcp: join: define tests groups once") 3c082695e78b ("selftests: mptcp: drop msg argument of chk_csum_nr") 69c6ce7b6eca ("selftests: mptcp: add implicit endpoint test case") 4cf86ae84c71 ("mptcp: strict local address ID selection") d045b9eb95a9 ("mptcp: introduce implicit endpoints") 6fa0174a7c86 ("mptcp: more careful RM_ADDR generation")

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From 1c1f721375989579e46741f59523e39ec9b2a9bd Mon Sep 17 00:00:00 2001
From: "Matthieu Baerts (NGI0)" <[email protected]>
Date: Mon, 19 Aug 2024 21:45:27 +0200
Subject: [PATCH] mptcp: pm: only decrement add_addr_accepted for MPJ req

Adding the following warning ...

WARN_ON_ONCE(msk->pm.add_addr_accepted == 0)

... before decrementing the add_addr_accepted counter helped to find a bug when running the "remove single subflow" subtest from the mptcp_join.sh selftest.

Removing a 'subflow' endpoint will first trigger a RM_ADDR, then the subflow closure. Before this patch, and upon the reception of the RM_ADDR, the other peer will then try to decrement this add_addr_accepted. That's not correct because the attached subflows have not been created upon the reception of an ADD_ADDR.

A way to solve that is to decrement the counter only if the attached subflow was an MP_JOIN to a remote id that was not 0, and initiated by the host receiving the RM_ADDR.

index 4cf7cc851f80..882781571c7b 100644
@@ -829,7 +829,7 @@ static void mptcp_pm_nl_rm_addr_or_subflow(struct mptcp_sock *msk,
 			mptcp_close_ssk(sk, ssk, subflow);
 			spin_lock_bh(&msk->pm.lock);
 
-			removed = true;
+			removed |= subflow->request_join;
 			if (rm_type == MPTCP_MIB_RMSUBFLOW)
 				__MPTCP_INC_STATS(sock_net(sk), rm_type);
 		}

@@ -843,7 +843,11 @@ static void mptcp_pm_nl_rm_addr_or_subflow(struct mptcp_sock *msk,
 		if (!mptcp_pm_is_kernel(msk))
 			continue;
 
-		if (rm_type == MPTCP_MIB_RMADDR) {
+		if (rm_type == MPTCP_MIB_RMADDR && rm_id &&
+		    !WARN_ON_ONCE(msk->pm.add_addr_accepted == 0)) {
+			/* Note: if the subflow has been closed before, this
+			 * add_addr_accepted counter will not be decremented.
+			 */
 			msk->pm.add_addr_accepted--;
 			WRITE_ONCE(msk->pm.accept_addr, true);
 		}

Hi Greg,

Thank you for the notification!

(...)

The code is too different in v5.10, and I don't think it is worth it to have this small fix in v5.10.

Cheers,
Matt

Sponsored by the NGI0 Core fund.