mptcp: Build-Fix

[Upstream commit af5a27078efdcb3076cfed10764cd0885e08027e]

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

[Upstream commit 8da14cd2bae471e2c9607cd9410da8272afaeb6c]

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

[Upstream commit 31581a0ad196e69a5da0d1c5adfa0427cd64f0e4]

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

[Upstream commit 98af406ca98be6e45703ff7c818b4a9f9d2a43c3]

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

[Upstream commit f2548af3b9714062cbd244953b64fdf945fd2d08]

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.

[Upstream commit 120a9bfab89e2fc3c9e737f8e3e98b474ae2e271]

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

[Upstream commit 6c74cda902314d74a0bea9da7a4239b7ef08e5a6]

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>