Re: [PATCH 5.15] mptcp: do not wait for bare sockets' timeout

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Fri, Feb 17, 2023 at 02:37:33PM +0100, Matthieu Baerts wrote:
> From: Paolo Abeni <pabeni@redhat.com>
> 
> [ Upstream commit d4e85922e3e7ef2071f91f65e61629b60f3a9cf4 ]
> 
> If the peer closes all the existing subflows for a given
> mptcp socket and later the application closes it, the current
> implementation let it survive until the timewait timeout expires.
> 
> While the above is allowed by the protocol specification it
> consumes resources for almost no reason and additionally
> causes sporadic self-tests failures.
> 
> Let's move the mptcp socket to the TCP_CLOSE state when there are
> no alive subflows at close time, so that the allocated resources
> will be freed immediately.
> 
> Fixes: e16163b6e2b7 ("mptcp: refactor shutdown and close")
> Cc: stable@vger.kernel.org
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
> ---
> Hi Greg, Sasha,
> 
> Here is one MPTCP patch backport that recently failed to apply to the
> 5.15 stable tree: it clears resources earlier if there is no more
> reasons to keep MPTCP sockets alive.
> 
> I had a simple conflict because in v5.15, the context is a bit different
> when iterating over the different subflows in __mptcp_close() but the
> idea is still the same: in this loop, a counter needs to be incremented.

Now queued up, thanks.

greg k-h