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