mptcp: Handle address-events differently

Up to now, the path-manager created an event that was put in the
event-queue. This event however already held the address-id taken from
mptcp_local. So, if we have a quick succession of address
add/del-commands (as it may happen for PPP) of the same address, we
might loose events because the address-id's don't match.

This patch modifys the path-manager so that it really only creates the
event and adds it to the event-queue without an id. The address-worker
then handles the real address-id and all the other stuff.

Path-manager is still not 100% correct. If the socket is locked we might
miss address-removal events and not send the remove_address. We probably
will need to add an atomic bit-field to handle this.

Reported-by: Vinothkumar Vivekanandan <vvinoth@watchy.in>
Tested-by: Vinothkumar Vivekanandan <vvinoth@watchy.in>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: ipv6_pinfo alignement issue when creating the master_sk

There is a bug in inet6_create when the pinet6 pointer is initialized.
Due to alignement problem the pointer does not correspond to
offsetof(struct tcp6_sock, inet6). Indeed, the pointer is computed
as sizeof(struct tcp6_sock) - sizeof(struct ipv6_pinfo) which can cause
problem when padding is added.

Here is the output of pahole on an object compiled for the ARMv7
architecture that shows that the compiler added 4 bytes of padding:
struct tcp6_sock {
	struct tcp_sock            tcp;                  /*     0  1296 */
	/* --- cacheline 20 boundary (1280 bytes) was 16 bytes ago --- */
	struct ipv6_pinfo          inet6;                /*  1296   140 */
	/* --- cacheline 22 boundary (1408 bytes) was 28 bytes ago --- */

	/* size: 1440, cachelines: 23, members: 2 */
	/* padding: 4 */
	/* last cacheline: 32 bytes */
};

Even if the structure of inet6 is copied after mptcp_inherit_sk, there is a
allignment missmatch due to the incorrect pointer set in inet6_create (in
the meta_sk). The solution chosen is to copy the content of inet6 from the
meta_sk to the one of the master_sk similarly to what is done in the regular
TCP/IPv6 stack.

Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Rename for easy grepping

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Fix Bug #25: Unlock mutex in inet_csk_listen_stop

When destroying a meta-sk in inet_csk_listen_stop, we call
tcp_disconnect.
tcp_disconnect "reverts" an MPTCP-socket to a regular TCP-socket by
setting flags like tp->mpc back to 0. It does this, because NFS for
example (ab)uses tcp_disconnect to avoid creating new sockets.

Anyway, as tp->mpc is set to 0 on the meta, is_meta_sk() will always
return false. So, the mutex will never be unlocked, and potential
subsockets waiting in mptcp_sub_close_wq will sleep forever, resulting
in a hung task:

[624960.204059] INFO: task kworker/u4:0:3416 blocked for more than 120 seconds.
[624960.204075] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[624960.204084] kworker/u4:0 D ffffffff 0 3416 2 0x00000000
[624960.204100] Workqueue: mptcp_wq mptcp_sub_close_wq
[624960.204106] dcc36ec0 00000246 ed3dcf28 ffffffff dcc36ef4 93accfa5 00023842 00000000
[624960.204120] eb04c440 ed3dcee0 c15e9ee0 c15e9ee0 c15e9ee0 eb04c440 c15e9ee0 c107c0e2
[624960.204133] 93accfa5 00000125 00000000 00000000 93accfa5 ffffffff ed3dd430 001500e0
[624960.204146] Call Trace:
[624960.204157] [] ? sched_clock_local+0xb2/0x190
[624960.204165] [] ? check_preempt_wakeup+0x104/0x220
[624960.204173] [] ? schedule_preempt_disabled+0x5/0x10
[624960.204181] [] ? __mutex_lock_slowpath+0x14f/0x1d0
[624960.204189] [] ? mutex_lock+0x1d/0x40
[624960.204196] [] ? mptcp_sub_close_wq+0x1b/0xe0
[624960.204203] [] ? process_one_work+0x112/0x3b0
[624960.204211] [] ? xen_hypercall_xen_version+0x7/0x20
[624960.204219] [] ? xen_force_evtchn_callback+0x17/0x30
[624960.204227] [] ? worker_thread+0xfa/0x3b0
[624960.204234] [] ? manage_workers+0x290/0x290
[624960.204241] [] ? kthread+0xa3/0xb0
[624960.204248] [] ? ret_from_kernel_thread+0x1b/0x28
[624960.204256] [] ? kthread_freezable_should_stop+0x50/0x50
[624960.204263] sending NMI to all CPUs:

This patch fixes it, by adding a local variable to inet_csk_listen_stop.

Fixes: https://github.com/multipath-tcp/mptcp/issues/25
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>