All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthieu Baerts <matthieu.baerts@tessares.net>
To: Greg KH <gregkh@linuxfoundation.org>,
	Mat Martineau <mathew.j.martineau@linux.intel.com>
Cc: stable@vger.kernel.org, sashal@kernel.org,
	Paolo Abeni <pabeni@redhat.com>,
	"David S . Miller" <davem@davemloft.net>,
	MPTCP Upstream <mptcp@lists.linux.dev>
Subject: Re: [PATCH] mptcp: Do TCP fallback on early DSS checksum failure
Date: Wed, 25 May 2022 12:32:04 +0200	[thread overview]
Message-ID: <0648dc99-7465-871c-90a1-8a69f60d893c@tessares.net> (raw)
In-Reply-To: <Yo3gG9H8Sw/w7baR@kroah.com>

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

  reply	other threads:[~2022-05-25 10:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0648dc99-7465-871c-90a1-8a69f60d893c@tessares.net \
    --to=matthieu.baerts@tessares.net \
    --cc=davem@davemloft.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=mathew.j.martineau@linux.intel.com \
    --cc=mptcp@lists.linux.dev \
    --cc=pabeni@redhat.com \
    --cc=sashal@kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.