On Fri, Feb 17, 2023 at 02:37:33PM +0100, Matthieu Baerts wrote:
> From: Paolo Abeni <pabeni@xxxxxxxxxx>
>
> [ 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@xxxxxxxxxxxxxxx
> Signed-off-by: Paolo Abeni <pabeni@xxxxxxxxxx>
> Reviewed-by: Matthieu Baerts <matthieu.baerts@xxxxxxxxxxxx>
> Signed-off-by: Matthieu Baerts <matthieu.baerts@xxxxxxxxxxxx>
> Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
> Signed-off-by: Matthieu Baerts <matthieu.baerts@xxxxxxxxxxxx>
> ---
> 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
