Run mptcp_init before TCP initialization

Signed-off-by: Catalin Nicutar <catalin.nicutar@gmail.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: Take mpcb-mutex when acting upon address-event

We must do this, in order to prevent entering the address-worker while
inside mptcp_close.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: Reconstruct skb-mapping, if reinjection failed

mptcp_skb_entail changed seq and end_seq to a subflow-level. If the
reinjection thus fails, mptcp_transmit_skb_failed will put it back on
the reinject-queue.

We have to recover the mapping out of the linear TCP-header.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: Remove pointers to socket from subflows upon mptcp_close

Otherwise we will be accessing garbage from the subsockets, as socket will be freed after
the mptcp_close.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: triple-lock error when sending reset from mptcp_do_join_short

We may have the following path:
tcp_v4_do_rcv->mptcp_do_join_short->mptcp_v4_do_rcv->tcp_v4_send_reset.

ip_send_reply (from tcp_v4_send_reset) will try to take the lock on the
socket. However, we are already holding two locks. The listener and the
meta. Lockdep will complain here.

So, we propagate the reset-sending up to tcp_rcv_state_process.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: Set the correct lock-class for ALL subflows

Subsockets created on the client-side also needs the correct lock class.

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

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: Only send reset if necessary

Because, the socket may not be correctly initialized (e.g.,
mptcp_init4_subsockets failed). Then, rcv_mss is 0, and
__mptcp_select_window will fail with a 0 divide (called from
tcp_transmit_skb).

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: Always force-close subflows on tcp_disconnect

Because, afterwards meta_tp->window_clamp will be set to 0. Then, when
we retransmit our MP_FAIL, the socket will select a zero mss in
__mptcp_select_window. This will result in a crash if window-scaling is
turned off.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: Hold the subsocket lock in tcp_disconnect

Because, we set mpc to 0, which will mean that tcp_v4_rcv will take the
subsocket's lock. Then we may have a race.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: Set icsk_backoff to 0 upon successfull data-delivery

Otherwise, the RTO-timer will get slower and slower.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: Race condition while creating subsocket on the server-side

There may happen a race-condition, because tp->mpc is set to 0 in
mptcp_inherit_sk.

What happens:
tp->mpc is set to 0 while creating a new subflow, and added to the
socket-hash-table by tcp_v4_syn_recv_sock. Then, a new packet comes in,
and waits for the lock on the subflow (not on the meta, because tp->mpc
is still 0).

In mptcp_add_sock, tp->mpc will finally be correctly set to 1. But hell,
this is too late. The above packet already came in. We have now a race,
as we are inside a subsocket, without holding the meta-socket lock.

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

Reported-by: Gregory Detal <gregory.detal@uclouvain.be>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: Rebuild the mapping on the subflow when fragmenting or trimming

If we loose a mapping due to fragmenting or trimming, the reinjection
cannot work. This will then require the meta-level retransmission timer
to trigger the recovery. This is very slow and may even lead to stalls.

We now reconstruct the mapping when fragmenting or trimming. This allows
us to quickly recover from the loss. In __mptcp_reinject_data, we have
to look for the data from the meta-send-queue in order to reinject it
properly.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: NULL-pointer exception in mptcp_del_sock

9c2c649cc57 (Fix: Race condition while creating subsocket on the
server-side) introduced a regression when mptcp_check_req_child fails.
tp->mpc is set, but tp->mptcp not yet. Then, in mptcp_del_sock we will
have a NULL Pointer Exception.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: Consider data-fin when checking if the mapping is coherent

If multiple packets cover a single mapping, and a data-fin is part of
this mapping, then the check in mptcp_detect_mapping is wrong.

map_data_len is data_len - 1, if a data-fin is present. We have to
consider this.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: Don't check for mptcp-flag data-fin in mptcp_queue_skb

If we receive a data-fin, mptcp_prepare_skb will set tcp_hdr()->fin to
1. If the mapping covers multiple segments however, mptcp_flags will
have the data-fin flag set on each of these segments.

Thus, we should rather check on the more accurate tcp_hdr()->fin flag,
which is only set on the real last segment.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Use tcp_try_coalesce in the meta-rcv and ofo-queue

This reduces the pressure on the receive-buffer as segments will be
coalesced better.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Merge branch 'mptcp_trunk' into mptcp_trunk_3.5.x