Fix: Free mptcp_tcp_sock also for the meta-sk

Otherwise we have a memory-leak.

Why didn't kmemleak report it... ???

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Reviewed-by: Octavian Purdila <octavian.purdila@intel.com>
Fix: Check for mptcp_is_data_seq in mptcp_verif_dss_csum

dss_off is set in mptcp_parse_options, irregardless of whether a
data-seq is present, or not.
Thus, we have to check in mptcp_verif_dss_csum based on the data-seq
number. Otherwise we will have problems if the mapping covers multiple
segments, with one of them holding the data-seq and the others just
data-acks.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Reviewed-by: Octavian Purdila <octavian.purdila@intel.com>
Fix: Always lock the socket in mptcp_inherit_sk

Previously we did not lock if it was the meta-sk on the server-side.

This creates the following race:
In mptcp_check_req_master we allocate the mpcb and set child_tp->mpc to
1. Thus, if a new segment comes in while still being inside
mptcp_check_req_master, this segment will take the meta-lock in
tcp_v4_rcv. So, we are processing the third ack and this new segment in
the master-sk at the same time.

Fix is easy:
Always take the lock in mptcp_inherit_sk and unlock it again in
tcp_child_process.

There is one problem with lockdep-checks. As we take the meta-lock we
take three locks of the same class: The listener-sock in tcp_v4_rcv, the
master-sk in sk_clone and finally the meta-sk in mptcp_inherit_sk. Thus,
lockdep will complain.

We create a custom lock-class for the meta-sk. That way lockdep won't
complain anymore.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Reviewed-by: Octavian Purdila <octavian.purdila@intel.com>
Fix: Fully destroy the socket if mptcp_check_req_child/master fails

The refcnt is initialized to 2 by sk_clone. Thus, we have to do a
sock_put, before calling tcp_done, who will do the final sock_put in
inet_csk_destroy_sock.

Additionally, unlock the sockets - their lock has been taken in
mptcp_inherit_sk

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Reviewed-by: Octavian Purdila <octavian.purdila@intel.com>
Fix: Don't always set treq->pktopts in mptcp_v6_join_request

It is only allowed, if the socket accepts IPv6-options.

Generally mptcp_v6_join_request needs a review. See Bug#82 on the
bugzilla.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Reviewed-by: Octavian Purdila <octavian.purdila@intel.com>
Fix: Don't modify reinjected skb if tcp_transmit_skb fails.

If there was a reinjection, subskb == skb. As we call kfree_skb() or
mptcp_wmem_free_skb on the subskb, we cannot access skb anymore.
Otherwise we have data-corruption of the skb.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Reviewed-by: Octavian Purdila <octavian.purdila@intel.com>
Fix: Correctly check if the meta-sk still accepts new subflows.

In mptcp_close() we remove the collide_tk from the token-table. By
calling list_del_init() we ensure that list_empty() will return True and
thus can correctly check in mptcp_v4_do_rcv if the socket is still ready
to accept new subflows.

sock_orphan is not enough, because in mptcp_close we may call
release_sock before sock_orphan in sk_stream_wait_close.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Reviewed-by: Octavian Purdila <octavian.purdila@intel.com>
Fix: Remove reqsk from request-queue in case of error

mptcp_v4_join_request did not really remove the request-sock from the
reqsk-queue in case of failure. Thus, the queue was corrupted, because
the req-sk was freed but not removed from the list.

We have to call inet_csk_search_req to get the prev-pointer. Then we can
remove it with a call to drop.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Reviewed-by: Octavian Purdila <octavian.purdila@intel.com>
Fix: Purge reinject-queue in tcp_disconnect

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Reviewed-by: Octavian Purdila <octavian.purdila@intel.com>