FAILED: patch "[PATCH] mptcp: fully established after ADD_ADDR echo on MPJ" failed to apply to 5.15-stable tree

The patch below does not apply to the 5.15-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.15.y
git checkout FETCH_HEAD
git cherry-pick -x d67c5649c1541dc93f202eeffc6f49220a4ed71d
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<[email protected]>' --in-reply-to '2024081209-wrongly-zen-35f3@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^..

Possible dependencies:

d67c5649c154 ("mptcp: fully established after ADD_ADDR echo on MPJ") b3ea6b272d79 ("mptcp: consolidate initial ack seq generation") f3589be0c420 ("mptcp: never shrink offered window")

thanks,

greg k-h

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

From d67c5649c1541dc93f202eeffc6f49220a4ed71d Mon Sep 17 00:00:00 2001
From: "Matthieu Baerts (NGI0)" <[email protected]>
Date: Wed, 31 Jul 2024 13:05:53 +0200
Subject: [PATCH] mptcp: fully established after ADD_ADDR echo on MPJ

Before this patch, receiving an ADD_ADDR echo on the just connected MP_JOIN subflow -- initiator side, after the MP_JOIN 3WHS -- was resulting in an MP_RESET. That's because only ACKs with a DSS or ADD_ADDRs without the echo bit were allowed.

Not allowing the ADD_ADDR echo after an MP_CAPABLE 3WHS makes sense, as we are not supposed to send an ADD_ADDR before because it requires to be in full established mode first. For the MP_JOIN 3WHS, that's different:
the ADD_ADDR can be sent on a previous subflow, and the ADD_ADDR echo can be received on the recently created one. The other peer will already be in fully established, so it is allowed to send that.

We can then relax the conditions here to accept the ADD_ADDR echo for MPJ subflows.

index 8a68382a4fe9..ac2f1a54cc43 100644
@@ -958,7 +958,8 @@ static bool check_fully_established(struct mptcp_sock *msk, struct sock *ssk,
 
 	if (subflow->remote_key_valid &&
 	    (((mp_opt->suboptions & OPTION_MPTCP_DSS) && mp_opt->use_ack) ||
-	     ((mp_opt->suboptions & OPTION_MPTCP_ADD_ADDR) && !mp_opt->echo))) {
+	     ((mp_opt->suboptions & OPTION_MPTCP_ADD_ADDR) &&
+	      (!mp_opt->echo || subflow->mp_join)))) {
 		/* subflows are fully established as soon as we get any
 		 * additional ack, including ADD_ADDR.
 		 */

commit d67c5649c1541dc93f202eeffc6f49220a4ed71d upstream.

Before this patch, receiving an ADD_ADDR echo on the just connected MP_JOIN subflow -- initiator side, after the MP_JOIN 3WHS -- was resulting in an MP_RESET. That's because only ACKs with a DSS or ADD_ADDRs without the echo bit were allowed.

Not allowing the ADD_ADDR echo after an MP_CAPABLE 3WHS makes sense, as we are not supposed to send an ADD_ADDR before because it requires to be in full established mode first. For the MP_JOIN 3WHS, that's different:
the ADD_ADDR can be sent on a previous subflow, and the ADD_ADDR echo can be received on the recently created one. The other peer will already be in fully established, so it is allowed to send that.

We can then relax the conditions here to accept the ADD_ADDR echo for MPJ subflows.

[ Conflicts in options.c, because the context has changed in commit
b3ea6b272d79 ("mptcp: consolidate initial ack seq generation"), which is not in this version. This commit is unrelated to this modification. ]

---
 net/mptcp/options.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

index 4d8f2f6a8f73..2baed0c01922 100644
@@ -923,7 +923,8 @@ static bool check_fully_established(struct mptcp_sock *msk, struct sock *ssk,
 	}
 
 	if (((mp_opt->suboptions & OPTION_MPTCP_DSS) && mp_opt->use_ack) ||
-	    ((mp_opt->suboptions & OPTION_MPTCP_ADD_ADDR) && !mp_opt->echo)) {
+	    ((mp_opt->suboptions & OPTION_MPTCP_ADD_ADDR) &&
+	     (!mp_opt->echo || subflow->mp_join))) {
 		/* subflows are fully established as soon as we get any
 		 * additional ack, including ADD_ADDR.
 		 */

2.45.2

Now queued up, thanks.

greg k-h

This is a note to let you know that I've just added the patch titled

mptcp: fully established after ADD_ADDR echo on MPJ

to the 5.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
mptcp-fully-established-after-add_addr-echo-on-mpj.patch
and it can be found in the queue-5.15 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

From [email protected] Tue Aug 13 12:47:13 2024
From: "Matthieu Baerts (NGI0)" <[email protected]>
Date: Tue, 13 Aug 2024 12:46:43 +0200
Subject: mptcp: fully established after ADD_ADDR echo on MPJ
To: [email protected], [email protected]
Cc: MPTCP Upstream <[email protected]>, "Matthieu Baerts (NGI0)" <[email protected]>, Mat Martineau <[email protected]>, Jakub Kicinski <[email protected]>
Message-ID: <[email protected]>

From: "Matthieu Baerts (NGI0)" <[email protected]>

commit d67c5649c1541dc93f202eeffc6f49220a4ed71d upstream.

Before this patch, receiving an ADD_ADDR echo on the just connected MP_JOIN subflow -- initiator side, after the MP_JOIN 3WHS -- was resulting in an MP_RESET. That's because only ACKs with a DSS or ADD_ADDRs without the echo bit were allowed.

Not allowing the ADD_ADDR echo after an MP_CAPABLE 3WHS makes sense, as we are not supposed to send an ADD_ADDR before because it requires to be in full established mode first. For the MP_JOIN 3WHS, that's different:
the ADD_ADDR can be sent on a previous subflow, and the ADD_ADDR echo can be received on the recently created one. The other peer will already be in fully established, so it is allowed to send that.

We can then relax the conditions here to accept the ADD_ADDR echo for MPJ subflows.

[ Conflicts in options.c, because the context has changed in commit
b3ea6b272d79 ("mptcp: consolidate initial ack seq generation"), which is not in this version. This commit is unrelated to this modification. ]

---
 net/mptcp/options.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

@@ -923,7 +923,8 @@ static bool check_fully_established(stru
 	}
 
 	if (((mp_opt->suboptions & OPTION_MPTCP_DSS) && mp_opt->use_ack) ||
-	    ((mp_opt->suboptions & OPTION_MPTCP_ADD_ADDR) && !mp_opt->echo)) {
+	    ((mp_opt->suboptions & OPTION_MPTCP_ADD_ADDR) &&
+	     (!mp_opt->echo || subflow->mp_join))) {
 		/* subflows are fully established as soon as we get any
 		 * additional ack, including ADD_ADDR.
 		 */

Patches currently in stable-queue which might be from [email protected] are

queue-5.15/netfilter-nf_tables-bail-out-if-stateful-expression-provides-no-.clone.patch queue-5.15/pci-dpc-fix-use-after-free-on-concurrent-dpc-and-hot-removal.patch queue-5.15/netfilter-nf_tables-set-element-extended-ack-reporting-support.patch queue-5.15/mptcp-fix-nl-pm-announced-address-accounting.patch queue-5.15/mptcp-distinguish-rcv-vs-sent-backup-flag-in-requests.patch queue-5.15/mptcp-pm-fix-backup-support-in-signal-endpoints.patch queue-5.15/netfilter-nf_tables-prefer-nft_chain_validate.patch queue-5.15/mptcp-mib-count-mpj-with-backup-flag.patch queue-5.15/selftests-mptcp-join-validate-backup-in-mpj.patch queue-5.15/netfilter-nf_tables-allow-clone-callbacks-to-sleep.patch queue-5.15/mptcp-export-local_address.patch queue-5.15/mptcp-pm-only-set-request_bkup-flag-when-sending-mp_prio.patch queue-5.15/mptcp-fix-bad-rcvpruned-mib-accounting.patch queue-5.15/netfilter-nf_tables-use-timestamp-to-check-for-set-element-timeout.patch queue-5.15/mptcp-fully-established-after-add_addr-echo-on-mpj.patch