mptcp: Fix integer overflow in olia

We need to cast the 32-bit int. Otherwise 32-bit arithmetic will be
done.

Fixes: 514e1d11669c9 (Initial OLIA-implementation)
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Correctly search for TCP/request-sockets even if they get recycled

It may be that a TCP/request-socket gets recycled and then ends up in
another part of the hash-list. If this happens while we are looking up
for a token in the hash-list, we have been moved to the wrong list and
will never find what we are looking for.

So, we need to do the same thing as in __inet_lookup_establish, check
the nulls-value and restart if necessary.

Fixes: eabc34bfa1d3b (Make the tk-table rcu-style)
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Some hlist-nulls function-cleanup

Just returning bool where possible and adding some const-qualifiers to
allow the compiler to optimize the code.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Check the token and net-ns again after taking refcnt in mptcp_hash_find

Same logic as in __inet_lookup_established. Between the first if and the
atomic_inc, the socket may get released and recycled again. So, we must
check a second time, after taking the refcnt.

Fixes: eabc34bfa1d3b (Make the tk-table rcu-style)
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Do not zero-out the tk_table in tcp_sock

hlist-nulls RCU lists relies on the fact that the next-pointer is never set to
NULL. However, if a TCP-socket is recycled it gets initialized to 0.

We need to do the same as in tcp_v6_clear_sk, which prevents clearing
the pinet6-pointer as it is also RCU-based.

Issues #54: https://github.com/multipath-tcp/mptcp/issues/54

Cc: John Ronan <jpronans@gmail.com>
Fixes: eabc34bfa1d3b (Make the tk-table rcu-style)
Reported-by: John Ronan <jpronans@gmail.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Fix IPv6 subflows on pure v4 sockets

Creating an IPv6 subflow on a pure IPv4 meta-socket (not a v6/v4-mapped socket)
crashes at the moment in tcp_v6_init_req, because we access the pinet6-pointer
from the meta-sk. As the meta is a v4-only socket, this results in a kernel panic,
because the pinet6-pointer is set to NULL:

[   45.740000] Pid: 0, comm: swapper Not tainted 3.14.0-netkit-mptcp
[   45.740000] RIP: 0033:[<000000006035d707>]
[   45.740000] RSP: 0000000060503588  EFLAGS: 00010246
[   45.740000] RAX: 0000000000000000 RBX: 000000006f791e00 RCX: 0000000000000011
[   45.740000] RDX: 0000000000001111 RSI: 00000000700ab940 RDI: 000000006f703040
[   45.740000] RBP: 000000006f703040 R08: 0000000060503670 R09: 0000000000000000
[   45.740000] R10: 0000000000000000 R11: 00000000603a89b0 R12: 00000000700ab940
[   45.740000] R13: 0000000000000000 R14: 00000000605eeba0 R15: 0000000060535ee0
[   45.740000] Kernel panic - not syncing: Segfault with no mm
[   45.740000] CPU: 0 PID: 0 Comm: swapper Not tainted 3.14.0-netkit-mptcp #493
[   45.740000] Stack:
[   45.740000]  6038bde2 00000000 6f791e00 700ab940
[   45.740000]  6f703040 6f635ac0 603ad4b4 00000020
[   45.740000]  6f791e00 6f703040 6f791e00 6f703040
[   45.740000] Call Trace:
[   45.740000]  [<6038bde2>] ? tcp_v6_init_req+0xb2/0x100
[   45.740000]  [<603ad4b4>] ? mptcp_v6_join_init_req+0x34/0xe0
[   45.740000]  [<602fccc5>] ? tcp_conn_request+0x2d5/0x6e0
[   45.740000]  [<6039d8f3>] ? __inet6_lookup_established+0x43/0x1e0
[   45.740000]  [<6039462f>] ? inet6_csk_search_req+0x3f/0x130
[   45.740000]  [<6038d91a>] ? tcp_v6_hnd_req+0xca/0x150
[   45.740000]  [<603acbf7>] ? mptcp_v6_do_rcv+0x127/0x380
[   45.740000]  [<600392cc>] ? set_signals+0x3c/0x50
[   45.740000]  [<603a939a>] ? mptcp_do_join_short+0x9a/0x200
[   45.740000]  [<6039e776>] ? mptcp_conn_request+0x166/0x230
[   45.740000]  [<6039d8f3>] ? __inet6_lookup_established+0x43/0x1e0
[   45.740000]  [<6039462f>] ? inet6_csk_search_req+0x3f/0x130
[   45.740000]  [<603009e8>] ? tcp_rcv_state_process+0x1c8/0x9a0
[   45.740000]  [<6038daba>] ? tcp_v6_do_rcv+0x11a/0x4e0
[   45.740000]  [<6038e76a>] ? tcp_v6_rcv+0x8ea/0x9a0

This bug has a quite some history:

Initially the issue was added by 6188b878fd6b5 (Fix Bug#82: Review mptcp_vX_join_request),
but the bug never really triggered because the sysctl tcp_tw_recycle must be
set to 1 in order to trigger it and isn must be != 0.

Then, 2ff7e7164fbd (Fix: SYN+ACK w/ MP_JOIN annouces a zero window) added
a call to inet6_csk_router_req, as it is done for regular TCP. Since then,
the bug triggers always if an IPv6 subflow gets established on a v4 pure
meta-socket.

This patch fixes it, by checking the np-pointer in tcp_v6_init_req as
well as reproduce inet6_csk_route_req in the route_req function-pointer.

All of this is actually quite ugly, as we yet again have to hack
inet6_csk_route_req because there is no pinet6-pointer on our meta-sk.

Octavian and Doru's work on mptcp_inherit_sk/mptcp_sk_clone should allow
to clean this up in the future.

Fixes: 6188b878fd6b5 (Fix Bug#82: Review mptcp_vX_join_request)
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Allow scheduler-specific per-subflow information

For example, the default-scheduler uses the variable last_rbuf_opti.
This can be moved to a "private" structure in reserved data in the
mptcp_tcp_sock. That way other schedulers can use the same reserved data
without increasing the size of mptcp_tcp_sock.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Add a round-robin scheduler

For research-purposes, a simple round-robin scheduler.

See:
http://inl.info.ucl.ac.be/publications/experimental-evaluation-multipath-tcp-schedulers

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