Cleanup

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix cnt_established accounting

The problem is, that if we enter mptcp_set_state and sk->sk_state is
already TCP_CLOSE, and we somehow try again to set the state to closed,
cnt_established will get decremented twice for this subsocket.

This fix contains multiple changes:

1. Check for tp->mpc at the caller of mptcp_set_state and not inside
   mptcp_set_state itself.
2. In mptcp_sub_close, prevent calling tcp_close_state, if the state of
   the subsocket is already TCP_CLOSE. It's pointless then.
3. In mptcp_set_state, don't change cnt_established, if sk->sk_state is
   already TCP_CLOSE. Because, if it is already closed, mptcp_set_state
   has already decremented cnt_estblished.

Additionally, I use tp instead of tcp_sk(sk) in mptcp_set_state.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Use tcp_push_pending_frames

tcp_push sets the urgent-pointer or marks segments as "push". This
should only be done coming from tcp_sendmsg. So, in the mptcp-stack we
should just use tcp_push_pending_frames.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: Respect draft, Section 3.3.5

We should only accept window-updates if they increase the largest
sequence number allowed.

Section 3.3.5 (v09):
The sender remembers receiver window advertisements from the
receiver.  It should only update its local receive window values when
the largest sequence number allowed (i.e.  DATA_ACK + receive window)
increases.  This is important to allow using paths with different
RTTs, and thus different feedback loops.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: Race in mptcp_syn_recv_sock

In mptcp_vX_search_req, we hold the mptcp_reqsk_hlock to protect the
request-sock list.
However, in mptcp_syn_recv_sock, we don't hold this lock anymore, and
thus the request-sock may have been freed before dereferencing the
meta-sk out of the request-sock.

This fix returns the meta_sk from mptcp_vX_search_req instead of
returning the request-sock. The request-sock was anyway not really
needed in mptcp_syn_recv_sock.

Also updated the outdated comments of mptcp_vX_search_req and removed
the WARN_ON out of this function.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: Look for established sockets in mptcp_vX_do_rcv

If we receive the third ack of a new subflow and directly after that a
data-segment. This data-segment will block on the meta-lock in
mptcp_syn_recv_sock, because the third ack has not yet been processed.

Regular TCP handles this by calling inet_lookup_established in
tcp_vX_hnd_req. We didn't do this.

Thus, this problem is fixed by calling tcp_vX_hnd_req and restructuring
a little bit the code in mptcp_vX_do_rcv so that we can use the
return-value of tcp_vX_hnd_req.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: Set tp->advmss to mptcp_sysctl_mss

It is set in tcp_vX_syn_recv_sock to dst_metric_advmss(dst), which is
calculated based on the MTU of the interface.
E.g., if MTU = 9000 but the sysctl mptcp_mss is 1400, tp->advmss should
be 1400 and not based on the MTU of 9000.

This will bring problems in tcp_rcv_space_adjust, as we calculate the
skb-truesize estimation based on tp->advmss.

Thus, this patch fixes tp->advmss in mptcp_check_req_* to
mptcp_sysctl_mss().

Additionally, it prevents all changes to tp->advmss in different
functions, by adding a check for tp->mpc.
Same in tcp_make_synack, where we change the mss only in the non-mptcp
case.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: Never ever reduce sk_rcv/sndbuf

Because then we will trigger the first condition in
tcp_try_rmem_schedule and drop the segment.

We should not abruptly reduce the rcv/snd-buffers.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: Handle sock_owned_by_user in mptcp_pm_addr_event_handler

If the socket is owned by the user and we enter
mptcp_pm_addr_event_handler, the sockets will get corrupted as we are
inside the critical region from the bottom-half address-handler and the
user-context.

We fix this, by adding the usual check of sock_owned_by_user in
mptcp_pm_addr_event_handler.
If the socket is owned by the user, we create a work-queue that will
handle the address-update.

However, we cannot pass the ptr from the addr-handler to the work-queue,
as he may have disappeared when the work-queue will get executed. Or a
new address-event may have happened and for example the address has come
up again.

So, in the work-queue we iterate over all addresses and check if they
exist inside the mpcb->addr4. If not, we add it, or update it.
Then we iterate over the addresses in mpcb->addr4 and check if there
exists a corresponding address on one of the interfaces. If not, we
remove this address.

This patch introduces quite some code-duplication in the
address-handling code. I will refactor later.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: In close_wait we can also reinject

mptcp_retransmit_queue should also allow reinjecting in close-wait
state.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>