mptcp: Fullmesh pathmanager: Fix event-handling in case of "multipath on"

If the "multipath on"-flag changes, we schedule a MOD-event. Later when
parsing the sockets we thus will never trigger the creation of new
subflows.

This patch transforms the MOD-event into an ADD-event so that it gets
handled correctly later on.

Reported-by: Kristian Walsh <kristian.walsh@quantumvpn.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Select correct ack-sock when removing subflows.

We must make sure that the ack-sock we select is the one who is still
operational. We achieve this by checking the pf-flag of the subflow when
choosing the ack-sock. In order to make sure that the pf-flag is set, we
call mptcp_reinject_data before calling update_remove_addr so that the
correct ack-sock is chosen.

Reported-by: John Ronan <jpronans@gmail.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Don't reinject empty data-fins on the same subflow

An empty data-fin might get lost on a subflow. If it would have hold
data, then the subflow-level RTO would have reinjected that data-fin on
another subflow and set the tp->pf flag to 1. This would then have
prevented this same subflow to be selected twice for the data-fin.

However, currently mptcp_dont_reinject will always select the same
subflow for empty data-fins even if it has been lost.

We must make sure that the empty data-fin is sent in a round-robin
fashion in case of RTOs as it is done for regular data.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
New stable release v0.88.8

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: use SOCK_NOSPACE instead of sk_write_pending

An application that wants to send data and is blocked on the send
buffer will end up in sk_stream_wait_memory where the sk_write_pending
is increased during the time the application waits for buffer space.
MPTCP uses this information to penalize slow subflows.

This works for regular sockets, unfortunately non-blocking sockets will
not increase sk_write_pending as they wont wait for more memory. However,
regular and non-blocking sockets always set the SOCK_NOSPACE flag if they
are send buffer limited.

Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Use del_init_rcu to reinitialize the pointers

Apparently strange things might happen otherwise...

Fixes: Bug #27 (https://github.com/multipath-tcp/mptcp/issues/27)
Reported-by: chenjianqing <https://github.com/cjqing0925>
Tested-by: chenjianqing <https://github.com/cjqing0925>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Fix union in tcp_out_options

It may be that a MP_CAPABLE is combined with an ADD_ADDR if there is
enough option-space. Then, the address will overwrite the key in the
MP_CAPABLE because it's within the same union in tcp_out_options.

We thus cannot use a union here.

Reported-by: Krishna Khanal <erkrishna.khanal@gmail.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Merge remote-tracking branch 'upstream/mptcp_v0.88' into mptcp_v0.88_binder_v6