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@xxxxxxxxxxxxxxx> # 5.17.x >>>> Cc: <stable@xxxxxxxxxxxxxxx> # 5.15.x >>>> Fixes: dd8bcd1768ff ("mptcp: validate the data checksum") >>>> Acked-by: Paolo Abeni <pabeni@xxxxxxxxxx> >>>> Signed-off-by: Mat Martineau <mathew.j.martineau@xxxxxxxxxxxxxxx> >>>> Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx> >>>> [mathew.j.martineau: backport: Resolved bitfield conflict in protocol.h] >>>> Signed-off-by: Mat Martineau <mathew.j.martineau@xxxxxxxxxxxxxxx> >>>> --- >>>> >>>> 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@xxxxxxxxxxxxxxx/ >>> >>> 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
