[PATCH mptcp-next v2 0/2] mptcp: fix another close hang-up

Paolo Abeni posted 2 patches 9 months, 3 weeks ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/multipath-tcp/mptcp_net-next tags/patchew/cover.1693322440.git.pabeni@redhat.com
Maintainers: Matthieu Baerts <matthieu.baerts@tessares.net>, Mat Martineau <martineau@kernel.org>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>
There is a newer version of this series
net/mptcp/protocol.c | 123 +++++++++++++++++++++----------------------
net/mptcp/protocol.h |  22 +++++++-
net/mptcp/subflow.c  |   3 +-
3 files changed, 84 insertions(+), 64 deletions(-)
[PATCH mptcp-next v2 0/2] mptcp: fix another close hang-up
Posted by Paolo Abeni 9 months, 3 weeks ago
If the TCP subflows close silently due to timeouts, the msk socket
can hang-up indefinitely.

Implement an additional close timeout triggered with the last subflow
close event and move the msk to TCP_CLOSE when it fires.

Should address issues/430 and issues/431.

v1 -> v2:
 - fix timeout timer scheduling in patch 2/2 (timeout never fired on v1)

Paolo Abeni (2):
  mptcp: rename timer related helper to less confusing names
  mptcp: implement connection level timeout.

 net/mptcp/protocol.c | 123 +++++++++++++++++++++----------------------
 net/mptcp/protocol.h |  22 +++++++-
 net/mptcp/subflow.c  |   3 +-
 3 files changed, 84 insertions(+), 64 deletions(-)

-- 
2.41.0
Re: [PATCH mptcp-next v2 0/2] mptcp: fix another close hang-up
Posted by Paolo Abeni 9 months, 3 weeks ago
On Tue, 2023-08-29 at 17:39 +0200, Paolo Abeni wrote:
> If the TCP subflows close silently due to timeouts, the msk socket
> can hang-up indefinitely.
> 
> Implement an additional close timeout triggered with the last subflow
> close event and move the msk to TCP_CLOSE when it fires.
> 
> Should address issues/430 and issues/431.
> 
> v1 -> v2:
>  - fix timeout timer scheduling in patch 2/2 (timeout never fired on v1)
 
As per last Daire feedback, even this revision don't fix the issue for
good, so please this series on-old.

I think that at very least this does not set/trigger the socket error
at close time, plus possibly we will need to make the timeout
configurable.

/P