All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] mptcp: Do TCP fallback on early DSS checksum failure
@ 2022-05-24 18:10 Mat Martineau
  2022-05-25  7:51 ` Greg KH
  0 siblings, 1 reply; 7+ messages in thread
From: Mat Martineau @ 2022-05-24 18:10 UTC (permalink / raw)
  To: stable
  Cc: Mat Martineau, gregkh, sashal, matthieu.baerts, Paolo Abeni,
	David S . Miller

[ Upstream commit ae66fb2ba6c3dcaf8b9612b65aa949a1a4bed150 ]

RFC 8684 section 3.7 describes several opportunities for a MPTCP
connection to "fall back" to regular TCP early in the connection
process, before it has been confirmed that MPTCP options can be
successfully propagated on all SYN, SYN/ACK, and data packets. If a peer
acknowledges the first received data packet with a regular TCP header
(no MPTCP options), fallback is allowed.

If the recipient of that first data packet finds a MPTCP DSS checksum
error, this provides an opportunity to fail gracefully with a TCP
fallback rather than resetting the connection (as might happen if a
checksum failure were detected later).

This commit modifies the checksum failure code to attempt fallback on
the initial subflow of a MPTCP connection, only if it's a failure in the
first data mapping. In cases where the peer initiates the connection,
requests checksums, is the first to send data, and the peer is sending
incorrect checksums (see
https://github.com/multipath-tcp/mptcp_net-next/issues/275), this allows
the connection to proceed as TCP rather than reset.

Cc: <stable@vger.kernel.org> # 5.17.x
Cc: <stable@vger.kernel.org> # 5.15.x
Fixes: dd8bcd1768ff ("mptcp: validate the data checksum")
Acked-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[mathew.j.martineau: backport: Resolved bitfield conflict in protocol.h]
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
---

This patch is already in 5.17.10-rc1 and 5.15.42-rc1, but involves a
context dependency on upstream commit 4cf86ae84c71 which I have
requested to be dropped from the stable queues.

I'm posting this backport without the protocol.h conflict to
(hopefully?) make it easier for the stable maintainers to drop
4cf86ae84c71.

For context see https://lore.kernel.org/stable/fa953ec-288f-7715-c6fb-47a222e85270@linux.intel.com/

Thanks,

Mat

---
net/mptcp/protocol.h |  3 ++-
 net/mptcp/subflow.c  | 21 ++++++++++++++++++---
 2 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index aec767ee047a..46b343a0b17e 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -442,7 +442,8 @@ struct mptcp_subflow_context {
 		rx_eof : 1,
 		can_ack : 1,        /* only after processing the remote a key */
 		disposable : 1,	    /* ctx can be free at ulp release time */
-		stale : 1;	    /* unable to snd/rcv data, do not use for xmit */
+		stale : 1,	    /* unable to snd/rcv data, do not use for xmit */
+		valid_csum_seen : 1;        /* at least one csum validated */
 	enum mptcp_data_avail data_avail;
 	u32	remote_nonce;
 	u64	thmac;
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index 651f01d13191..8d5ddf8e3ef7 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -913,11 +913,14 @@ static enum mapping_status validate_data_csum(struct sock *ssk, struct sk_buff *
 				 subflow->map_data_csum);
 	if (unlikely(csum)) {
 		MPTCP_INC_STATS(sock_net(ssk), MPTCP_MIB_DATACSUMERR);
-		subflow->send_mp_fail = 1;
-		MPTCP_INC_STATS(sock_net(ssk), MPTCP_MIB_MPFAILTX);
+		if (subflow->mp_join || subflow->valid_csum_seen) {
+			subflow->send_mp_fail = 1;
+			MPTCP_INC_STATS(sock_net(ssk), MPTCP_MIB_MPFAILTX);
+		}
 		return subflow->mp_join ? MAPPING_INVALID : MAPPING_DUMMY;
 	}
 
+	subflow->valid_csum_seen = 1;
 	return MAPPING_OK;
 }
 
@@ -1099,6 +1102,18 @@ static void subflow_sched_work_if_closed(struct mptcp_sock *msk, struct sock *ss
 	}
 }
 
+static bool subflow_can_fallback(struct mptcp_subflow_context *subflow)
+{
+	struct mptcp_sock *msk = mptcp_sk(subflow->conn);
+
+	if (subflow->mp_join)
+		return false;
+	else if (READ_ONCE(msk->csum_enabled))
+		return !subflow->valid_csum_seen;
+	else
+		return !subflow->fully_established;
+}
+
 static bool subflow_check_data_avail(struct sock *ssk)
 {
 	struct mptcp_subflow_context *subflow = mptcp_subflow_ctx(ssk);
@@ -1176,7 +1191,7 @@ static bool subflow_check_data_avail(struct sock *ssk)
 		return true;
 	}
 
-	if (subflow->mp_join || subflow->fully_established) {
+	if (!subflow_can_fallback(subflow)) {
 		/* fatal protocol error, close the socket.
 		 * subflow_error_report() will introduce the appropriate barriers
 		 */
-- 
2.36.1


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH] mptcp: Do TCP fallback on early DSS checksum failure
  2022-05-24 18:10 [PATCH] mptcp: Do TCP fallback on early DSS checksum failure Mat Martineau
@ 2022-05-25  7:51 ` Greg KH
  2022-05-25 10:32   ` Matthieu Baerts
  0 siblings, 1 reply; 7+ messages in thread
From: Greg KH @ 2022-05-25  7:51 UTC (permalink / raw)
  To: Mat Martineau
  Cc: stable, sashal, matthieu.baerts, Paolo Abeni, David S . Miller

On Tue, May 24, 2022 at 11:10:41AM -0700, Mat Martineau wrote:
> [ Upstream commit ae66fb2ba6c3dcaf8b9612b65aa949a1a4bed150 ]
> 
> RFC 8684 section 3.7 describes several opportunities for a MPTCP
> connection to "fall back" to regular TCP early in the connection
> process, before it has been confirmed that MPTCP options can be
> successfully propagated on all SYN, SYN/ACK, and data packets. If a peer
> acknowledges the first received data packet with a regular TCP header
> (no MPTCP options), fallback is allowed.
> 
> If the recipient of that first data packet finds a MPTCP DSS checksum
> error, this provides an opportunity to fail gracefully with a TCP
> fallback rather than resetting the connection (as might happen if a
> checksum failure were detected later).
> 
> This commit modifies the checksum failure code to attempt fallback on
> the initial subflow of a MPTCP connection, only if it's a failure in the
> first data mapping. In cases where the peer initiates the connection,
> requests checksums, is the first to send data, and the peer is sending
> incorrect checksums (see
> https://github.com/multipath-tcp/mptcp_net-next/issues/275), this allows
> the connection to proceed as TCP rather than reset.
> 
> Cc: <stable@vger.kernel.org> # 5.17.x
> Cc: <stable@vger.kernel.org> # 5.15.x
> Fixes: dd8bcd1768ff ("mptcp: validate the data checksum")
> Acked-by: Paolo Abeni <pabeni@redhat.com>
> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> [mathew.j.martineau: backport: Resolved bitfield conflict in protocol.h]
> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
> ---
> 
> This patch is already in 5.17.10-rc1 and 5.15.42-rc1, but involves a
> context dependency on upstream commit 4cf86ae84c71 which I have
> requested to be dropped from the stable queues.
> 
> I'm posting this backport without the protocol.h conflict to
> (hopefully?) make it easier for the stable maintainers to drop
> 4cf86ae84c71.
> 
> For context see https://lore.kernel.org/stable/fa953ec-288f-7715-c6fb-47a222e85270@linux.intel.com/

THanks, will take this after this round of releases.

greg k-h

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] mptcp: Do TCP fallback on early DSS checksum failure
  2022-05-25  7:51 ` Greg KH
@ 2022-05-25 10:32   ` Matthieu Baerts
  2022-05-25 12:25     ` Greg KH
  0 siblings, 1 reply; 7+ messages in thread
From: Matthieu Baerts @ 2022-05-25 10:32 UTC (permalink / raw)
  To: Greg KH, Mat Martineau
  Cc: stable, sashal, Paolo Abeni, David S . Miller, MPTCP Upstream

Hi Greg, Mat,

On 25/05/2022 09:51, Greg KH wrote:
> On Tue, May 24, 2022 at 11:10:41AM -0700, Mat Martineau wrote:
>> [ Upstream commit ae66fb2ba6c3dcaf8b9612b65aa949a1a4bed150 ]
>>
>> RFC 8684 section 3.7 describes several opportunities for a MPTCP
>> connection to "fall back" to regular TCP early in the connection
>> process, before it has been confirmed that MPTCP options can be
>> successfully propagated on all SYN, SYN/ACK, and data packets. If a peer
>> acknowledges the first received data packet with a regular TCP header
>> (no MPTCP options), fallback is allowed.
>>
>> If the recipient of that first data packet finds a MPTCP DSS checksum
>> error, this provides an opportunity to fail gracefully with a TCP
>> fallback rather than resetting the connection (as might happen if a
>> checksum failure were detected later).
>>
>> This commit modifies the checksum failure code to attempt fallback on
>> the initial subflow of a MPTCP connection, only if it's a failure in the
>> first data mapping. In cases where the peer initiates the connection,
>> requests checksums, is the first to send data, and the peer is sending
>> incorrect checksums (see
>> https://github.com/multipath-tcp/mptcp_net-next/issues/275), this allows
>> the connection to proceed as TCP rather than reset.
>>
>> Cc: <stable@vger.kernel.org> # 5.17.x
>> Cc: <stable@vger.kernel.org> # 5.15.x
>> Fixes: dd8bcd1768ff ("mptcp: validate the data checksum")
>> Acked-by: Paolo Abeni <pabeni@redhat.com>
>> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
>> Signed-off-by: David S. Miller <davem@davemloft.net>
>> [mathew.j.martineau: backport: Resolved bitfield conflict in protocol.h]
>> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
>> ---
>>
>> This patch is already in 5.17.10-rc1 and 5.15.42-rc1, but involves a
>> context dependency on upstream commit 4cf86ae84c71 which I have
>> requested to be dropped from the stable queues.
>>
>> I'm posting this backport without the protocol.h conflict to
>> (hopefully?) make it easier for the stable maintainers to drop
>> 4cf86ae84c71.
>>
>> For context see https://lore.kernel.org/stable/fa953ec-288f-7715-c6fb-47a222e85270@linux.intel.com/
> 
> THanks, will take this after this round of releases.

It might already be too late but is it possible to have this patch
("mptcp: Do TCP fallback on early DSS checksum failure") and "mptcp: fix
checksum byte order" in the same stable release?

Note that "mptcp: fix checksum byte order" patch has been recently
queued by Sasha at the same time as "mptcp: Do TCP fallback on early DSS
checksum failure".

A bit of context: "mptcp: fix checksum byte order" fixes an important
encoding issue but it also breaks the interoperability with previous
Linux versions not having this patch.

The patch from Mat ("mptcp: Do TCP fallback on early DSS checksum
failure") improves the situation when there is this interoperability
issue with a previous Linux versions not implementing the RFC properly.
The improvement is there to make the MPTCP connections falling back to
TCP instead of resetting them: at least there is a connection.

In other words, that would be really nice to have these two commits
backported together. If it is easier, it looks best to me to delay the
main fix ("mptcp: fix checksum byte order") than having the two patches
in different stable versions. But I understand it was not clear and
maybe too late to do these modifications.

Anyway, thank you for your work maintaining these stable versions! :)

Cheers,
Matt
-- 
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] mptcp: Do TCP fallback on early DSS checksum failure
  2022-05-25 10:32   ` Matthieu Baerts
@ 2022-05-25 12:25     ` Greg KH
  2022-05-25 12:36       ` Matthieu Baerts
  0 siblings, 1 reply; 7+ messages in thread
From: Greg KH @ 2022-05-25 12:25 UTC (permalink / raw)
  To: Matthieu Baerts
  Cc: Mat Martineau, stable, sashal, Paolo Abeni, David S . Miller,
	MPTCP Upstream

On Wed, May 25, 2022 at 12:32:04PM +0200, Matthieu Baerts wrote:
> Hi Greg, Mat,
> 
> On 25/05/2022 09:51, Greg KH wrote:
> > On Tue, May 24, 2022 at 11:10:41AM -0700, Mat Martineau wrote:
> >> [ Upstream commit ae66fb2ba6c3dcaf8b9612b65aa949a1a4bed150 ]
> >>
> >> RFC 8684 section 3.7 describes several opportunities for a MPTCP
> >> connection to "fall back" to regular TCP early in the connection
> >> process, before it has been confirmed that MPTCP options can be
> >> successfully propagated on all SYN, SYN/ACK, and data packets. If a peer
> >> acknowledges the first received data packet with a regular TCP header
> >> (no MPTCP options), fallback is allowed.
> >>
> >> If the recipient of that first data packet finds a MPTCP DSS checksum
> >> error, this provides an opportunity to fail gracefully with a TCP
> >> fallback rather than resetting the connection (as might happen if a
> >> checksum failure were detected later).
> >>
> >> This commit modifies the checksum failure code to attempt fallback on
> >> the initial subflow of a MPTCP connection, only if it's a failure in the
> >> first data mapping. In cases where the peer initiates the connection,
> >> requests checksums, is the first to send data, and the peer is sending
> >> incorrect checksums (see
> >> https://github.com/multipath-tcp/mptcp_net-next/issues/275), this allows
> >> the connection to proceed as TCP rather than reset.
> >>
> >> Cc: <stable@vger.kernel.org> # 5.17.x
> >> Cc: <stable@vger.kernel.org> # 5.15.x
> >> Fixes: dd8bcd1768ff ("mptcp: validate the data checksum")
> >> Acked-by: Paolo Abeni <pabeni@redhat.com>
> >> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
> >> Signed-off-by: David S. Miller <davem@davemloft.net>
> >> [mathew.j.martineau: backport: Resolved bitfield conflict in protocol.h]
> >> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
> >> ---
> >>
> >> This patch is already in 5.17.10-rc1 and 5.15.42-rc1, but involves a
> >> context dependency on upstream commit 4cf86ae84c71 which I have
> >> requested to be dropped from the stable queues.
> >>
> >> I'm posting this backport without the protocol.h conflict to
> >> (hopefully?) make it easier for the stable maintainers to drop
> >> 4cf86ae84c71.
> >>
> >> For context see https://lore.kernel.org/stable/fa953ec-288f-7715-c6fb-47a222e85270@linux.intel.com/
> > 
> > THanks, will take this after this round of releases.
> 
> It might already be too late but is it possible to have this patch
> ("mptcp: Do TCP fallback on early DSS checksum failure") and "mptcp: fix
> checksum byte order" in the same stable release?
> 
> Note that "mptcp: fix checksum byte order" patch has been recently
> queued by Sasha at the same time as "mptcp: Do TCP fallback on early DSS
> checksum failure".
> 
> A bit of context: "mptcp: fix checksum byte order" fixes an important
> encoding issue but it also breaks the interoperability with previous
> Linux versions not having this patch.
> 
> The patch from Mat ("mptcp: Do TCP fallback on early DSS checksum
> failure") improves the situation when there is this interoperability
> issue with a previous Linux versions not implementing the RFC properly.
> The improvement is there to make the MPTCP connections falling back to
> TCP instead of resetting them: at least there is a connection.
> 
> In other words, that would be really nice to have these two commits
> backported together. If it is easier, it looks best to me to delay the
> main fix ("mptcp: fix checksum byte order") than having the two patches
> in different stable versions. But I understand it was not clear and
> maybe too late to do these modifications.
> 
> Anyway, thank you for your work maintaining these stable versions! :)

I have already done a release with the first change in it, sorry, but
have queued this up now.  Given that this is fixing a problem with that
commit, I'll go do a release right now for 5.17 and 5.15.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] mptcp: Do TCP fallback on early DSS checksum failure
  2022-05-25 12:25     ` Greg KH
@ 2022-05-25 12:36       ` Matthieu Baerts
  2022-05-25 12:45         ` Greg KH
  0 siblings, 1 reply; 7+ messages in thread
From: Matthieu Baerts @ 2022-05-25 12:36 UTC (permalink / raw)
  To: Greg KH
  Cc: Mat Martineau, stable, sashal, Paolo Abeni, David S . Miller,
	MPTCP Upstream

On 25/05/2022 14:25, Greg KH wrote:
> On Wed, May 25, 2022 at 12:32:04PM +0200, Matthieu Baerts wrote:
>> Hi Greg, Mat,
>>
>> On 25/05/2022 09:51, Greg KH wrote:
>>> On Tue, May 24, 2022 at 11:10:41AM -0700, Mat Martineau wrote:
>>>> [ Upstream commit ae66fb2ba6c3dcaf8b9612b65aa949a1a4bed150 ]
>>>>
>>>> RFC 8684 section 3.7 describes several opportunities for a MPTCP
>>>> connection to "fall back" to regular TCP early in the connection
>>>> process, before it has been confirmed that MPTCP options can be
>>>> successfully propagated on all SYN, SYN/ACK, and data packets. If a peer
>>>> acknowledges the first received data packet with a regular TCP header
>>>> (no MPTCP options), fallback is allowed.
>>>>
>>>> If the recipient of that first data packet finds a MPTCP DSS checksum
>>>> error, this provides an opportunity to fail gracefully with a TCP
>>>> fallback rather than resetting the connection (as might happen if a
>>>> checksum failure were detected later).
>>>>
>>>> This commit modifies the checksum failure code to attempt fallback on
>>>> the initial subflow of a MPTCP connection, only if it's a failure in the
>>>> first data mapping. In cases where the peer initiates the connection,
>>>> requests checksums, is the first to send data, and the peer is sending
>>>> incorrect checksums (see
>>>> https://github.com/multipath-tcp/mptcp_net-next/issues/275), this allows
>>>> the connection to proceed as TCP rather than reset.
>>>>
>>>> Cc: <stable@vger.kernel.org> # 5.17.x
>>>> Cc: <stable@vger.kernel.org> # 5.15.x
>>>> Fixes: dd8bcd1768ff ("mptcp: validate the data checksum")
>>>> Acked-by: Paolo Abeni <pabeni@redhat.com>
>>>> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
>>>> Signed-off-by: David S. Miller <davem@davemloft.net>
>>>> [mathew.j.martineau: backport: Resolved bitfield conflict in protocol.h]
>>>> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
>>>> ---
>>>>
>>>> This patch is already in 5.17.10-rc1 and 5.15.42-rc1, but involves a
>>>> context dependency on upstream commit 4cf86ae84c71 which I have
>>>> requested to be dropped from the stable queues.
>>>>
>>>> I'm posting this backport without the protocol.h conflict to
>>>> (hopefully?) make it easier for the stable maintainers to drop
>>>> 4cf86ae84c71.
>>>>
>>>> For context see https://lore.kernel.org/stable/fa953ec-288f-7715-c6fb-47a222e85270@linux.intel.com/
>>>
>>> THanks, will take this after this round of releases.
>>
>> It might already be too late but is it possible to have this patch
>> ("mptcp: Do TCP fallback on early DSS checksum failure") and "mptcp: fix
>> checksum byte order" in the same stable release?
>>
>> Note that "mptcp: fix checksum byte order" patch has been recently
>> queued by Sasha at the same time as "mptcp: Do TCP fallback on early DSS
>> checksum failure".
>>
>> A bit of context: "mptcp: fix checksum byte order" fixes an important
>> encoding issue but it also breaks the interoperability with previous
>> Linux versions not having this patch.
>>
>> The patch from Mat ("mptcp: Do TCP fallback on early DSS checksum
>> failure") improves the situation when there is this interoperability
>> issue with a previous Linux versions not implementing the RFC properly.
>> The improvement is there to make the MPTCP connections falling back to
>> TCP instead of resetting them: at least there is a connection.
>>
>> In other words, that would be really nice to have these two commits
>> backported together. If it is easier, it looks best to me to delay the
>> main fix ("mptcp: fix checksum byte order") than having the two patches
>> in different stable versions. But I understand it was not clear and
>> maybe too late to do these modifications.
>>
>> Anyway, thank you for your work maintaining these stable versions! :)
> 
> I have already done a release with the first change in it, sorry, but
> have queued this up now.  Given that this is fixing a problem with that
> commit, I'll go do a release right now for 5.17 and 5.15.

I'm sorry for the troubles this is causing you but thank you for doing that!

Please note that on the bright side, the DSS Checksum feature is
disabled by default so hopefully, this interoperability issue should not
affect too many people. It is hard to quantify but I guess there is no
need to rush if you prefer to wait before doing this release.

Cheers,
Matt
-- 
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] mptcp: Do TCP fallback on early DSS checksum failure
  2022-05-25 12:36       ` Matthieu Baerts
@ 2022-05-25 12:45         ` Greg KH
  2022-05-25 12:50           ` Matthieu Baerts
  0 siblings, 1 reply; 7+ messages in thread
From: Greg KH @ 2022-05-25 12:45 UTC (permalink / raw)
  To: Matthieu Baerts
  Cc: Mat Martineau, stable, sashal, Paolo Abeni, David S . Miller,
	MPTCP Upstream

On Wed, May 25, 2022 at 02:36:10PM +0200, Matthieu Baerts wrote:
> On 25/05/2022 14:25, Greg KH wrote:
> > On Wed, May 25, 2022 at 12:32:04PM +0200, Matthieu Baerts wrote:
> >> Hi Greg, Mat,
> >>
> >> On 25/05/2022 09:51, Greg KH wrote:
> >>> On Tue, May 24, 2022 at 11:10:41AM -0700, Mat Martineau wrote:
> >>>> [ Upstream commit ae66fb2ba6c3dcaf8b9612b65aa949a1a4bed150 ]
> >>>>
> >>>> RFC 8684 section 3.7 describes several opportunities for a MPTCP
> >>>> connection to "fall back" to regular TCP early in the connection
> >>>> process, before it has been confirmed that MPTCP options can be
> >>>> successfully propagated on all SYN, SYN/ACK, and data packets. If a peer
> >>>> acknowledges the first received data packet with a regular TCP header
> >>>> (no MPTCP options), fallback is allowed.
> >>>>
> >>>> If the recipient of that first data packet finds a MPTCP DSS checksum
> >>>> error, this provides an opportunity to fail gracefully with a TCP
> >>>> fallback rather than resetting the connection (as might happen if a
> >>>> checksum failure were detected later).
> >>>>
> >>>> This commit modifies the checksum failure code to attempt fallback on
> >>>> the initial subflow of a MPTCP connection, only if it's a failure in the
> >>>> first data mapping. In cases where the peer initiates the connection,
> >>>> requests checksums, is the first to send data, and the peer is sending
> >>>> incorrect checksums (see
> >>>> https://github.com/multipath-tcp/mptcp_net-next/issues/275), this allows
> >>>> the connection to proceed as TCP rather than reset.
> >>>>
> >>>> Cc: <stable@vger.kernel.org> # 5.17.x
> >>>> Cc: <stable@vger.kernel.org> # 5.15.x
> >>>> Fixes: dd8bcd1768ff ("mptcp: validate the data checksum")
> >>>> Acked-by: Paolo Abeni <pabeni@redhat.com>
> >>>> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
> >>>> Signed-off-by: David S. Miller <davem@davemloft.net>
> >>>> [mathew.j.martineau: backport: Resolved bitfield conflict in protocol.h]
> >>>> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
> >>>> ---
> >>>>
> >>>> This patch is already in 5.17.10-rc1 and 5.15.42-rc1, but involves a
> >>>> context dependency on upstream commit 4cf86ae84c71 which I have
> >>>> requested to be dropped from the stable queues.
> >>>>
> >>>> I'm posting this backport without the protocol.h conflict to
> >>>> (hopefully?) make it easier for the stable maintainers to drop
> >>>> 4cf86ae84c71.
> >>>>
> >>>> For context see https://lore.kernel.org/stable/fa953ec-288f-7715-c6fb-47a222e85270@linux.intel.com/
> >>>
> >>> THanks, will take this after this round of releases.
> >>
> >> It might already be too late but is it possible to have this patch
> >> ("mptcp: Do TCP fallback on early DSS checksum failure") and "mptcp: fix
> >> checksum byte order" in the same stable release?
> >>
> >> Note that "mptcp: fix checksum byte order" patch has been recently
> >> queued by Sasha at the same time as "mptcp: Do TCP fallback on early DSS
> >> checksum failure".
> >>
> >> A bit of context: "mptcp: fix checksum byte order" fixes an important
> >> encoding issue but it also breaks the interoperability with previous
> >> Linux versions not having this patch.
> >>
> >> The patch from Mat ("mptcp: Do TCP fallback on early DSS checksum
> >> failure") improves the situation when there is this interoperability
> >> issue with a previous Linux versions not implementing the RFC properly.
> >> The improvement is there to make the MPTCP connections falling back to
> >> TCP instead of resetting them: at least there is a connection.
> >>
> >> In other words, that would be really nice to have these two commits
> >> backported together. If it is easier, it looks best to me to delay the
> >> main fix ("mptcp: fix checksum byte order") than having the two patches
> >> in different stable versions. But I understand it was not clear and
> >> maybe too late to do these modifications.
> >>
> >> Anyway, thank you for your work maintaining these stable versions! :)
> > 
> > I have already done a release with the first change in it, sorry, but
> > have queued this up now.  Given that this is fixing a problem with that
> > commit, I'll go do a release right now for 5.17 and 5.15.
> 
> I'm sorry for the troubles this is causing you but thank you for doing that!
> 
> Please note that on the bright side, the DSS Checksum feature is
> disabled by default so hopefully, this interoperability issue should not
> affect too many people. It is hard to quantify but I guess there is no
> need to rush if you prefer to wait before doing this release.

No worries, it was easy to do a new release, now done!

greg k-h

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] mptcp: Do TCP fallback on early DSS checksum failure
  2022-05-25 12:45         ` Greg KH
@ 2022-05-25 12:50           ` Matthieu Baerts
  0 siblings, 0 replies; 7+ messages in thread
From: Matthieu Baerts @ 2022-05-25 12:50 UTC (permalink / raw)
  To: Greg KH
  Cc: Mat Martineau, stable, sashal, Paolo Abeni, David S . Miller,
	MPTCP Upstream

On 25/05/2022 14:45, Greg KH wrote:
> On Wed, May 25, 2022 at 02:36:10PM +0200, Matthieu Baerts wrote:
>> On 25/05/2022 14:25, Greg KH wrote:
>>> On Wed, May 25, 2022 at 12:32:04PM +0200, Matthieu Baerts wrote:
>>>> Hi Greg, Mat,
>>>>
>>>> On 25/05/2022 09:51, Greg KH wrote:
>>>>> On Tue, May 24, 2022 at 11:10:41AM -0700, Mat Martineau wrote:
>>>>>> [ Upstream commit ae66fb2ba6c3dcaf8b9612b65aa949a1a4bed150 ]
>>>>>>
>>>>>> RFC 8684 section 3.7 describes several opportunities for a MPTCP
>>>>>> connection to "fall back" to regular TCP early in the connection
>>>>>> process, before it has been confirmed that MPTCP options can be
>>>>>> successfully propagated on all SYN, SYN/ACK, and data packets. If a peer
>>>>>> acknowledges the first received data packet with a regular TCP header
>>>>>> (no MPTCP options), fallback is allowed.
>>>>>>
>>>>>> If the recipient of that first data packet finds a MPTCP DSS checksum
>>>>>> error, this provides an opportunity to fail gracefully with a TCP
>>>>>> fallback rather than resetting the connection (as might happen if a
>>>>>> checksum failure were detected later).
>>>>>>
>>>>>> This commit modifies the checksum failure code to attempt fallback on
>>>>>> the initial subflow of a MPTCP connection, only if it's a failure in the
>>>>>> first data mapping. In cases where the peer initiates the connection,
>>>>>> requests checksums, is the first to send data, and the peer is sending
>>>>>> incorrect checksums (see
>>>>>> https://github.com/multipath-tcp/mptcp_net-next/issues/275), this allows
>>>>>> the connection to proceed as TCP rather than reset.
>>>>>>
>>>>>> Cc: <stable@vger.kernel.org> # 5.17.x
>>>>>> Cc: <stable@vger.kernel.org> # 5.15.x
>>>>>> Fixes: dd8bcd1768ff ("mptcp: validate the data checksum")
>>>>>> Acked-by: Paolo Abeni <pabeni@redhat.com>
>>>>>> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
>>>>>> Signed-off-by: David S. Miller <davem@davemloft.net>
>>>>>> [mathew.j.martineau: backport: Resolved bitfield conflict in protocol.h]
>>>>>> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
>>>>>> ---
>>>>>>
>>>>>> This patch is already in 5.17.10-rc1 and 5.15.42-rc1, but involves a
>>>>>> context dependency on upstream commit 4cf86ae84c71 which I have
>>>>>> requested to be dropped from the stable queues.
>>>>>>
>>>>>> I'm posting this backport without the protocol.h conflict to
>>>>>> (hopefully?) make it easier for the stable maintainers to drop
>>>>>> 4cf86ae84c71.
>>>>>>
>>>>>> For context see https://lore.kernel.org/stable/fa953ec-288f-7715-c6fb-47a222e85270@linux.intel.com/
>>>>>
>>>>> THanks, will take this after this round of releases.
>>>>
>>>> It might already be too late but is it possible to have this patch
>>>> ("mptcp: Do TCP fallback on early DSS checksum failure") and "mptcp: fix
>>>> checksum byte order" in the same stable release?
>>>>
>>>> Note that "mptcp: fix checksum byte order" patch has been recently
>>>> queued by Sasha at the same time as "mptcp: Do TCP fallback on early DSS
>>>> checksum failure".
>>>>
>>>> A bit of context: "mptcp: fix checksum byte order" fixes an important
>>>> encoding issue but it also breaks the interoperability with previous
>>>> Linux versions not having this patch.
>>>>
>>>> The patch from Mat ("mptcp: Do TCP fallback on early DSS checksum
>>>> failure") improves the situation when there is this interoperability
>>>> issue with a previous Linux versions not implementing the RFC properly.
>>>> The improvement is there to make the MPTCP connections falling back to
>>>> TCP instead of resetting them: at least there is a connection.
>>>>
>>>> In other words, that would be really nice to have these two commits
>>>> backported together. If it is easier, it looks best to me to delay the
>>>> main fix ("mptcp: fix checksum byte order") than having the two patches
>>>> in different stable versions. But I understand it was not clear and
>>>> maybe too late to do these modifications.
>>>>
>>>> Anyway, thank you for your work maintaining these stable versions! :)
>>>
>>> I have already done a release with the first change in it, sorry, but
>>> have queued this up now.  Given that this is fixing a problem with that
>>> commit, I'll go do a release right now for 5.17 and 5.15.
>>
>> I'm sorry for the troubles this is causing you but thank you for doing that!
>>
>> Please note that on the bright side, the DSS Checksum feature is
>> disabled by default so hopefully, this interoperability issue should not
>> affect too many people. It is hard to quantify but I guess there is no
>> need to rush if you prefer to wait before doing this release.
> 
> No worries, it was easy to do a new release, now done!

Wow, our first MPTCP-only stable release! :-)

Again thank you!

Cheers,
Matt
-- 
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2022-05-25 12:50 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-24 18:10 [PATCH] mptcp: Do TCP fallback on early DSS checksum failure Mat Martineau
2022-05-25  7:51 ` Greg KH
2022-05-25 10:32   ` Matthieu Baerts
2022-05-25 12:25     ` Greg KH
2022-05-25 12:36       ` Matthieu Baerts
2022-05-25 12:45         ` Greg KH
2022-05-25 12:50           ` Matthieu Baerts

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.