More unions in the tcp_out_options structure

This is possible because sender_key and receiver_key are used only for
mp_capable, and sender_mac is used only for the third ack of a mp_join
handshake.

Signed-off-by: Andrei Maruseac <andrei.maruseac@intel.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
tcp: fix tcp_rcv_rtt_update() use of an unscaled RTT sample

[ Upstream commit 18a223e0b9ec8979320ba364b47c9772391d6d05 ]

Fix a code path in tcp_rcv_rtt_update() that was comparing scaled and
unscaled RTT samples.

The intent in the code was to only use the 'm' measurement if it was a
new minimum.  However, since 'm' had not yet been shifted left 3 bits
but 'new_sample' had, this comparison would nearly always succeed,
leading us to erroneously set our receive-side RTT estimate to the 'm'
sample when that sample could be nearly 8x too high to use.

The overall effect is to often cause the receive-side RTT estimate to
be significantly too large (up to 40% too large for brief periods in
my tests).

Signed-off-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
tcp: change tcp_adv_win_scale and tcp_rmem[2]

[ Upstream commit b49960a05e32121d29316cfdf653894b88ac9190 ]

tcp_adv_win_scale default value is 2, meaning we expect a good citizen
skb to have skb->len / skb->truesize ratio of 75% (3/4)

In 2.6 kernels we (mis)accounted for typical MSS=1460 frame :
1536 + 64 + 256 = 1856 'estimated truesize', and 1856 * 3/4 = 1392.
So these skbs were considered as not bloated.

With recent truesize fixes, a typical MSS=1460 frame truesize is now the
more precise :
2048 + 256 = 2304. But 2304 * 3/4 = 1728.
So these skb are not good citizen anymore, because 1460 < 1728

(GRO can escape this problem because it build skbs with a too low
truesize.)

This also means tcp advertises a too optimistic window for a given
allocated rcvspace : When receiving frames, sk_rmem_alloc can hit
sk_rcvbuf limit and we call tcp_prune_queue()/tcp_collapse() too often,
especially when application is slow to drain its receive queue or in
case of losses (netperf is fast, scp is slow). This is a major latency
source.

We should adjust the len/truesize ratio to 50% instead of 75%

This patch :

1) changes tcp_adv_win_scale default to 1 instead of 2

2) increase tcp_rmem[2] limit from 4MB to 6MB to take into account
better truesize tracking and to allow autotuning tcp receive window to
reach same value than before. Note that same amount of kernel memory is
consumed compared to 2.6 kernels.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Tom Herbert <therbert@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Always check for tp->mpc, not for mptcp

It is guaranteed that if tp->mpc is set, tp->mptcp is set too.
Always checking for tp->mpc facilitates the code and especially makes
tcp_disconnect possible in the follow-up patch.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Always check for tp->mpc, never for tp->mpcb

It is guaranteed that if tp->mpc is set, tp->mpcb is set too.
Always checking for tp->mpc facilitates the code and especially makes
tcp_disconnect possible in the follow-up patch.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
If we are in user-context we can directly close a socket

This avoids creating a work-queue if we can do it directly.

However, we have to call tcp_done before mptcp_sub_close in
mptcp_sub_force_close, to ensure that the socket will get destroyed if
we call mptcp_sub_force_close from user-context.
Previously it was OK to call tcp_done after mptcp_sub_close, because the
work-queue *always* executes after tcp_done, due to the lock in
mptcp_sub_close_wq. As we now call tcp_close in mptcp_sub_close if we
are in user-context, we have to move tcp_done upwards.

And replace some code in mptcp_mp_fail_rcvd by mptcp_sub_force_close.

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

Multiple changes in here to make SO_LINGER and thus also tcp_disconnect
work as it should:

1. mptcp_close has to handle SO_LINGER like in tcp_close.

2. Only call mptcp_hash_remove and reqsk_queue_destroy if it hasn't been
   removed/destroyed yet. Because, we may do mptcp_close and then
   tcp_disconnect. This would result in calling twice the above
   mentioned functions and thus we crash.

3. In tcp_disconnect, don't force-close the socket who has sent the
   FAST_CLOSE option (check for tp->send_mp_fclose).

4. In mptcp_sub_close_wq, call sock_put(sk) if the socket is non-mptcp.
   The corresponding sock_hold is in mptcp_sub_close.

5. In inet_sock_destruct we have to check for tp->mptcp, because tp->mpc
   has been set to 0 by tcp_disconnect.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Parse MPTCP options only when valid

This commit avoids that a potential attacker injects unwanted options in
the middle of a connection. From now on, the MPTCP options are parsed
only after the validation of the segment, i.e., in-window, PAWS, etc.

Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: fix mptcp_check_snd_buf to return number of packets instead of bytes

Added new bw estimation: bw_i = snd_cwnd_i / rtt_i and replaced the return value for mptcp_check_snd_buf with bw_i * rtt_max.
Removed the unused bw_est code.

Signed-off-by: Mihai P. Andrei <mihai.p.andrei@intel.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
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>
Cleanup

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