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>
initial support for LSRR in master socket, not active due to deadlock
bug when calling do_ip_setsockopt
Merge remote-tracking branch 'upstream/mptcp_trunk' into mptcp_trunk
Revert "patched makefile, to disable some optimisations for debugging purposes"

This reverts commit 73e460053d5aff69e3c4b4dc0794b5f7191712e8.