Merge branch 'mptcp-update-mptcp-ack-sequence-outside-of-recv-path'
authorDavid S. Miller <davem@davemloft.net>
Thu, 27 Feb 2020 04:46:26 +0000 (20:46 -0800)
committerDavid S. Miller <davem@davemloft.net>
Thu, 27 Feb 2020 04:46:26 +0000 (20:46 -0800)
commit621135a0f9cf512e477e5e9aa3e87ee96e896175
tree1e909ad2d71b864e798e2f14838dd756c398dad1
parent5cd129dd5e45b9c3c61ec373c3ec1d60925dc65d
parent14c441b564d560dea4c93947d5b40a992e13ca31
Merge branch 'mptcp-update-mptcp-ack-sequence-outside-of-recv-path'

Florian Westphal says:

====================
mptcp: update mptcp ack sequence outside of recv path

This series moves mptcp-level ack sequence update outside of the recvmsg path.
Current approach has two problems:

1. There is delay between arrival of new data and the time we can ack
   this data.
2. If userspace doesn't call recv for some time, mptcp ack_seq is not
   updated at all, even if this data is queued in the subflow socket
   receive queue.

Move skbs from the subflow socket receive queue to the mptcp-level
receive queue, updating the mptcp-level ack sequence and have recv
take skbs from the mptcp-level receive queue.

The first place where we will attempt to update the mptcp level acks
is from the subflows' data_ready callback, even before we make userspace
aware of new data.

Because of possible deadlock (we need to take the mptcp socket lock
while already holding the subflow sockets lock), we may still need to
defer the mptcp-level ack update.  In such case, this work will be either
done from work queue or recv path, depending on which runs sooner.

In order to avoid pointless scheduling of the work queue, work
will be queued from the mptcp sockets lock release callback.
This allows to detect when the socket owner did drain the subflow
socket receive queue.

Please see individual patches for more information.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>