From: David S. Miller Date: Thu, 27 Feb 2020 04:46:26 +0000 (-0800) Subject: Merge branch 'mptcp-update-mptcp-ack-sequence-outside-of-recv-path' X-Git-Tag: v5.15~4200^2~312 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=621135a0f9cf512e477e5e9aa3e87ee96e896175;p=platform%2Fkernel%2Flinux-starfive.git 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 --- 621135a0f9cf512e477e5e9aa3e87ee96e896175