Fix: olia: Divide by 0

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
drm/i915/sdvo: clean up connectors on intel_sdvo_init() failures

Any failures in intel_sdvo_init() after the intel_sdvo_setup_output() call
left behind ghost connectors, attached (with a dangling pointer) to the
sdvo that has been cleaned up and freed. Properly destroy any connectors
attached to the encoder.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46381
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org
Tested-by: bjo@nord-west.org
[danvet: added a comment to explain why we need to clean up connectors
even when sdvo_output_setup fails.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

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

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: Olia: Correctly scale in Olia

Provided by Ramin Khalili.
We have to use u64 in mptcp_olia_scale, because it's argument is u64.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix olia based on recommendation from Ramin

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: Memoryleak when processing backlog-queue

If the refcnt was already zero, we will not process the received
segment. We thus have to free it to avoid the memory-leak.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: Correctly destroy socket upon failure

When mptcp_create_master_sk fails, we have to destroy the meta too,
because the error gets propagated down to tcp_check_req, where we hit
the listen_overflow.

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

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: Handle meta-socket in inet_csk_listen_stop

We have to hold the mutex, to prevent any work-queue from accessing the
meta-sk while closing it.

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

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: Handle error-signals correctly while in fallback-mode

If we have fallen back to regular TCP, we should interpret a RST or any
other error-signal (e.g., coming from tcp_v4_err) as an error on the
whole connection.

This patch modifies mptcp_sock_def_error_report, to check on the
infinite-flags of the mpcb and propagate the error up to the
meta-socket.

Reported-by: Krishna Khanal <krishna.khanal2@citrix.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Tested-by: Krishna Khanal <krishna.khanal2@citrix.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: Let meta-socket timeout if no subflow is ready to reinject

If we go to out_reset_timer, icsk_retransmits will not get increased,
and the meta-socket will *never* time out, hanging around there forever.

This patch adds a new label, allowing icsk_retransmits to be
incremented, if no subflow is available for sending.

Reported-by: Justin Collery <justin.collery@quantumvpn.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>

Conflicts:
	net/mptcp/mptcp_output.c
Fix: Check for socket-state when combining dfin with subflow-fin

When checking if we can combine a data-fin with a subflow-fin, we look
if all subflows have nothing to send. We must check the socket's state,
because un-established sockets may still have the SYN-packet in their
write-queue.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: Close remaining subflows when the meta socket disappears

We may enter tcp_v4_destroy_sock, while there are still active subflows.
This may happen e.g., when the closure is unsuccessfull due to a
retransmission timeout (tcp_write_err). We should then close the
subflows, because otherwise they will hang around there forever, waiting
for a call to mptcp_sub_close - which will never happen.

We try to do graceful closure of the subflows (not using
mptcp_sub_force_close), as the subflows may still be usable - and we
always prefer graceful closure.

Reported-by: Justin Collery <justin.collery@quantumvpn.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Tested-by: Justin Collery <justin.collery@quantumvpn.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: Launch keepalive-timer on FIN_WAIT2-sockets

If the socket enters FIN_WAIT2 and he is dead, we have to launch the
keepalive-timer if we don't want to enter tcp_time_wait(). Otherwise he
will hang around there forever, because the app has already given up on
the socket, and no timer is referencing him anymore.

This code must get removed again as soon as we support TIME-WAIT-sockets
correctly.

Reported-by: Justin Collery <justin.collery@quantumvpn.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Tested-by: Justin Collery <justin.collery@quantumvpn.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Cleanup

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: Only send in-order data if the subflow is not yet fully established

Unless we are sure that the path/server supports MPTCP, we should only
send in-order data on a subflow.

This patch fixes this by adding a new variable, that tracks the last
end-data-seq sent on the subflow. This allows us to guarantee that the
data is in-order.

Reported-by: Krishna Khanal <krishna.khanal2@citrix.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Tested-by: Krishna Khanal <krishna.khanal2@citrix.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>

Conflicts:
	net/mptcp/mptcp_output.c
Fix: Send fourth ack after updating the windows

We have to make sure that the window and everything has been updated,
prior to sending the fourth ack. Thus, we move the call to tcp_send_ack
a little bit lower.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Fix: Store the original values of snd/rcv-buffers and use them

If we don't do this, the server-side new subflows have a bloated up
snd/rcv-buffer (as it's a clone from the meta). This will then end up in
strange values for rcv_wnd of the new subflow, and incorrect setting of
the subflow-level rcv_ssthresh. As the autotuning during slow-start is
handled by rcv_ssthresh, this incorrect setting prevents correct
autotuning.

This patch makes a first step, by storing the original values of
snd/rcv-buffer in the mpcb.
New subflows on the server-side will thus get correct buffer-sizes. This
will allow in a follow-up patch to correctly increase the
snd/rcv-buffers (and meta-level rcv_ssthresh) upon establishment of
new subflows and thus allow a proper autotuning during slowstart.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Increase rcv_ssthresh when adding a new subflow

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