From: Matthieu Baerts <matttbe@kernel.org>
To: gregkh@linuxfoundation.org, pabeni@redhat.com, kuba@kernel.org
Cc: stable@vger.kernel.org
Subject: Re: FAILED: patch "[PATCH] mptcp: be sure to send ack when mptcp-level window re-opens" failed to apply to 5.15-stable tree
Date: Wed, 22 Jan 2025 12:13:26 +0100 [thread overview]
Message-ID: <9b376aa3-a7b1-4791-9013-ac250d9f1393@kernel.org> (raw)
In-Reply-To: <2025012037-siesta-sulfite-8b05@gregkh>
Hi Greg,
On 20/01/2025 14:38, gregkh@linuxfoundation.org wrote:
>
> 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 <stable@vger.kernel.org>.
Thank you for the notification!
> ------------------ original commit in Linus's tree ------------------
>
> From 2ca06a2f65310aeef30bb69b7405437a14766e4d Mon Sep 17 00:00:00 2001
> From: Paolo Abeni <pabeni@redhat.com>
> Date: Mon, 13 Jan 2025 16:44:56 +0100
> Subject: [PATCH] mptcp: be sure to send ack when mptcp-level window re-opens
>
> mptcp_cleanup_rbuf() is responsible to send acks when the user-space
> reads enough data to update the receive windows significantly.
>
> It tries hard to avoid acquiring the subflow sockets locks by checking
> conditions similar to the ones implemented at the TCP level.
>
> To avoid too much code duplication - the MPTCP protocol can't reuse the
> TCP helpers as part of the relevant status is maintained into the msk
> socket - and multiple costly window size computation, mptcp_cleanup_rbuf
> uses a rough estimate for the most recently advertised window size:
> the MPTCP receive free space, as recorded as at last-ack time.
>
> Unfortunately the above does not allow mptcp_cleanup_rbuf() to detect
> a zero to non-zero win change in some corner cases, skipping the
> tcp_cleanup_rbuf call and leaving the peer stuck.
>
> After commit ea66758c1795 ("tcp: allow MPTCP to update the announced
> window"), MPTCP has actually cheap access to the announced window value.
> Use it in mptcp_cleanup_rbuf() for a more accurate ack generation.
FYI, we are currently not planning to backport this patch: it depends on
commits ea66758c1795 ("tcp: allow MPTCP to update the announced window")
-- mentioned above -- and f3589be0c420 ("mptcp: never shrink offered
window") which are not in this v5.15 version, and linked to new features.
The issue fixed by the patch here has not been seen on a v5.15 kernel so
far, and probably only visible with other changes that have been done
later on. In other words, it looks OK not to backport this patch.
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
prev parent reply other threads:[~2025-01-22 11:13 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-20 13:38 FAILED: patch "[PATCH] mptcp: be sure to send ack when mptcp-level window re-opens" failed to apply to 5.15-stable tree gregkh
2025-01-22 11:13 ` Matthieu Baerts [this message]
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=9b376aa3-a7b1-4791-9013-ac250d9f1393@kernel.org \
--to=matttbe@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=kuba@kernel.org \
--cc=pabeni@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox