mptcp: Fix tcp_may_send_now for MPTCP

[Upstream commit 5e8f2cda98fc55e9d24096226caed0c7192f356a]

There is one big issue in this function, in that it accesses
tcp_send_head from the meta_sk. However, at this point we have no
guarantee that the send-head is sane. The write-queue might have been
purged while the subflow is still up (e.g., a fast-close through
AbortOnData).

We will then access garbage through the skb and might crash:
(as reported by John Ronan)

[241288.160802] BUG: unable to handle kernel paging request at
00000000ffff8804
[241288.167899] IP: [<ffffffff815d345e>] tcp_init_tso_segs+0x1e/0x60
[241288.174026] PGD 0
[241288.176148] Oops: 0000 [#1] SMP
[241288.179499] Modules linked in: iptable_filter ip_tables x_tables
coretemp i7core_edac edac_core wmi lpc_ich ipmi_si ipmi_msghandler
tpm_tis dcdbas mac_hid psmouse lp serio_raw acpi_power_meter parport
hid_generic usbhid hid mpt2sas scsi_transport_sas raid_class bnx2
[241288.203502] CPU: 4 PID: 0 Comm: swapper/4 Not tainted
3.14.16-20140815-mpn-cppatches-amd64-d356bc832d+ #5
[241288.214384] Hardware name: Dell Inc. PowerEdge R410/01V648, BIOS
1.12.0 07/30/2013
[241288.222081] task: ffff88022696c7a0 ti: ffff880226976000 task.ti:
ffff880226976000
[241288.229681] RIP: 0010:[<ffffffff815d345e>] [<ffffffff815d345e>]
tcp_init_tso_segs+0x1e/0x60
[241288.238250] RSP: 0018:ffff88022fd03848  EFLAGS: 00010206
[241288.243665] RAX: 0000000000000534 RBX: ffff8800709a4400 RCX:
00000000ffff8800
[241288.250916] RDX: 0000000000000534 RSI: ffff8800709a4400 RDI:
ffff88006a18f380
[241288.258169] RBP: ffff88022fd03858 R08: 0000000000000000 R09:
0000000000000000
[241288.265423] R10: 00000000ffffffff R11: 0000000000000000 R12:
ffff8800cad53180
[241288.272675] R13: ffff88006a18f380 R14: 0000000000000534 R15:
0000000000000004
[241288.279926] FS:  0000000000000000(0000) GS:ffff88022fd00000(0000)
knlGS:0000000000000000
[241288.288135] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[241288.293983] CR2: 00000000ffff8804 CR3: 0000000001c0b000 CR4:
00000000000007e0
[241288.301236] Stack:
[241288.303347]  ffff8800709a4400 ffff8800709a4400 ffff88022fd03898
ffffffff815d35b6
[241288.310903]  ffff88022fd03800 ffff8800cad53180 0000000000000002
0000000000004120
[241288.318458]  0000000000000001 0000000000000001 ffff88022fd038f8
ffffffff815cb6e2
[241288.326014] Call Trace:
[241288.328561]  <IRQ>
[241288.330573]  [<ffffffff815d35b6>] tcp_may_send_now+0x76/0x140
[241288.336632]  [<ffffffff815cb6e2>] tcp_fastretrans_alert+0x1e2/0xb40
[241288.343005]  [<ffffffff815ccbc8>] tcp_ack+0x978/0x1060
[241288.348248]  [<ffffffff815ce805>] tcp_rcv_established+0x135/0x5e0
[241288.354448]  [<ffffffff815da5e5>] tcp_v4_do_rcv+0x1f5/0x3f0
[241288.360125]  [<ffffffff815db18f>] tcp_v4_rcv+0x85f/0x8d0

On another note, tcp_may_send_now should not rely on the meta-sk to
check if we should enter recovery. Nothing guarantees that if there is
data on the meta, ready to be sent, that it will be sent on the subflow
that experienced the loss. Due to this, we may not enter recovery, while
we actually should and the subflow will have an RTO.

It's the job of the scheduler to keep the subflow's send-queues sane so that
recovery works properly.

This is actually a revert of cbb6b3227f7 (mptcp: tcp_current_mss cannot
call mptcp_current_mss) and d1130dd78bf5 (mptcp: Don't scheduler
forward-retransmissions too often).

Fixes: d1130dd78bf5 (mptcp: Don't scheduler forward-retransmissions too often)
Cc: John Ronan <jpronans@gmail.com>
Reported-by: John Ronan <jpronans@gmail.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>