* Re: [PATCH] mptcp: Do TCP fallback on early DSS checksum failure [not found] ` <Yo3gG9H8Sw/w7baR@kroah.com> @ 2022-05-25 10:32 ` Matthieu Baerts 2022-05-25 12:25 ` Greg KH 0 siblings, 1 reply; 5+ 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] 5+ messages in thread
* Re: [PATCH] mptcp: Do TCP fallback on early DSS checksum failure 2022-05-25 10:32 ` [PATCH] mptcp: Do TCP fallback on early DSS checksum failure Matthieu Baerts @ 2022-05-25 12:25 ` Greg KH 2022-05-25 12:36 ` Matthieu Baerts 0 siblings, 1 reply; 5+ 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] 5+ 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; 5+ 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] 5+ 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; 5+ 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] 5+ 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; 5+ 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] 5+ messages in thread
end of thread, other threads:[~2022-05-25 12:50 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20220524181041.19543-1-mathew.j.martineau@linux.intel.com>
[not found] ` <Yo3gG9H8Sw/w7baR@kroah.com>
2022-05-25 10:32 ` [PATCH] mptcp: Do TCP fallback on early DSS checksum failure 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 a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).