[MPTCP] Re: [PATCH/RFC 0/7] improve subflow join handling

* [MPTCP] Re: [PATCH/RFC 0/7] improve subflow join handling
@ 2019-11-25 12:06 Paolo Abeni
  0 siblings, 0 replies; 5+ messages in thread
From: Paolo Abeni @ 2019-11-25 12:06 UTC (permalink / raw)
  To: mptcp

[-- Attachment #1: Type: text/plain, Size: 2327 bytes --]

On Mon, 2019-11-25 at 03:15 +0100, Florian Westphal wrote:
> This set aims to improve handling of multiple subflows.
> There are multiple remaining problems, see below, but I wanted to send what
> I have now rather than keep this back.
> 
> The first 3 patches are fixes to handle refcount leaks found while working
> on this, I've added the commit name of where they could be squashed to.
> 
> The remaining part of this work is to make the msk->conn_list contain
> tcp_sock structs without an outer 'struct socket'.
> 
> The problem is that for incoming join requests (which are not subject
> to accept/request socket queue), there is no 'struct socket', i.e.
> sk->sk_socket is NULL.
> 
> As tcp stack will assume that such tcp sk is already detached from
> userspace, SOCK_NOSPACE wakeups do not work for them.
> 
> The solution here (suggested by Paolo) is to have sk->sk_socket refer
> to the mptcp parent socket structure.  This assignment is done by
> a private function similar to sock_graft().
> 
> For incoming connects, tcp-level connectivity works, i.e. mptcp-next can
> accept a few subflows from the peer and on exit of the test program
> all resources are cleaned up correctly.
> 
> MPTCP-Level connectivity will probably not work, as nothing sets up
> ssn_offset for joins (both incoming or outgoing).
> 
> mptcp.org kernel will not consider the joins as established, as the
> "4th Ack" is missing.
> A simple "tcp_send_ack" is enough, but there are two problems with this:
> 1. It can be lost
> 2. Given we are not expecting to receive any data on such flows this
>    doesn't seem to be a problem.
> 
> During testing I saw that sometimes mptcp.org kernel will emit further
> join requests to mptcp-next but those trigger no response (and those
> packets do not even show up in perfs network drop monitor, sigh).
> 
> For outgoing connects, there is one remaining memory leak that I have
> not located so far.
> _______________________________________________
> mptcp mailing list -- mptcp(a)lists.01.org
> To unsubscribe send an email to mptcp-leave(a)lists.01.org

LGTM! I think the firs 3 patches can be squashed as-is. I have only a
couple of minor question on the last 2 patches, see later individual
replies...

Great work, BTW ;)

Thanks,

Paolo

^ permalink raw reply	[flat|nested] 5+ messages in thread