mptcp: Build-Fix

ERROR: "tcp_current_mss" [net/mptcp/mptcp_rr.ko] undefined!
make[2]: *** [__modpost] Error 1
make[1]: *** [modules] Error 2
make: *** [sub-make] Error 2

Fixes: 2c599d3 (mptcp: Add a round-robin scheduler)
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: Sébastien Barré <sebastien.barre@uclouvain.be>
mptcp: Do not increase icsk_backoff for empty retransmissions

In case of an empty retransmission, like in mptcp_ack_retransmit_timer
or fclose-retransmissions, we should not increase icsk_backoff.
Because, otherwise if an ICMP-unreachable comes back, in tcp_v4_err we
will not exit the switch case with:

if (seq != tp->snd_una  || !icsk->icsk_retransmits ||
    !icsk->icsk_backoff || fastopen)
	break;

And then crash as we access the write-queue's head.

Fixes: 4da0e692c5 (mptcp: Fix MPTCP FAST_CLOSE)
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: Sébastien Barré <sebastien.barre@uclouvain.be>
mptcp: Only become fully-established if subflow-data has been acked

In mptcp_data_ack, we check if the subflow is not yet fully established
and then verify that either data has been acknowledged on the data-level
and on the subflow-level.

But, only the subflow-level matters. We are sure that the ack contains a
DATA_ACK (thanks to the above checks). All we want to know is whether
the data that we did sent has been acknowledged, including a DATA_ACK.

Otherwise, it may happen that an incoming DATA-packet including a
DATA_ACK, with the ack-number different from the meta's snt_isn (e.g.,
because data has been sent and acked on another subflow) moves the
subflow to fully_established. But this incoming DATA_ACK is no
guarantee for a fully established subflow.

5b242d9412cc0 (Fix: Needless fallback) introduced this, because we were
expecting that at the same time than subflow-data is acked, the DATA_ACK
must also advance, which is not true when TSO is being used.

Fixes: 5b242d9412cc0 (Fix: Needless fallback)
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: Sébastien Barré <sebastien.barre@uclouvain.be>
mptcp: Fix sending backup-bit in SYN/ACK+MP_JOIN

In mptcp_options_write, we take the backup-bit from tp->mptcp->low_prio
on a SYN/ACK. But for SYN/ACK's tp is the meta-socket. low_prio does not
make any sense there.

We actually should store the low_prio-flag in the request-socket
like we do for the loc_id. So, we need to get the low_prio-flag from the
path-manager through get_local_id.

Fixes: eef5e912be4b4 (Allow setting non-master subflows as backup paths)
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: Sébastien Barré <sebastien.barre@uclouvain.be>
mptcp: Support request-sockets that move from one htb to another

As they may get recycled, they may also be moving from one htb to
another. We must use the same trick as in c25eb3bfb9729 by defining a
different NULLS value for request-sockets that go into the join-htb.

Fixes: eabc34bfa1d3b (Make the tk-table rcu-style)
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: Sébastien Barré <sebastien.barre@uclouvain.be>
mptcp: Initialize hash_entry early for join-requests.

Because, we may destroy the request-socket otherwise before pprev has
been set to NULL (if get_local_id fails). Then, reqsk_free will in
mptcp_hash_request_remove try to remove the reqsk if pprev is different
from NULL.

Fixes: 25109d9939062 (mptcp: rework mptcp_join_request)
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: Sébastien Barré <sebastien.barre@uclouvain.be>
mptcp: Remove request-sock from tk_htb if we fallback to regular TCP

A request-socket that in the beginning saw an MP_CAPABLE and then falls
back to regular TCP because the client gave up and sent us a SYN without
MP_CAPABLE is still sitting in the tk_htb. Because saw_mpc is 0, we will
exit mptcp_check_req_master and then the request-socket will remain in
the tk_htb. As it gets freed, we will have garbage in the htb and all
kind of funny things may happen.

This patch adds a new flag to inet_request_sock to indicate, whether
this request-socket is actually an mptcp_request_sock. That way we can
differentiate between regular TCP and fallback-regular TCP and remove
the request-socket if the latter is the case.

Fixes: Zero-day bug
Reported-by: John Ronan <jpronans@gmail.com>
Tested-by: John Ronan <jpronans@gmail.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: Sébastien Barré <sebastien.barre@uclouvain.be>