OSDN Git Service

Merge branch 'mptcp-do-not-block-on-subflow-socket'
authorDavid S. Miller <davem@davemloft.net>
Sun, 17 May 2020 19:35:35 +0000 (12:35 -0700)
committerDavid S. Miller <davem@davemloft.net>
Sun, 17 May 2020 19:35:35 +0000 (12:35 -0700)
commit9740a7ae6d5208897bf3ef49e8595dc4cfd323ee
tree11c8520bff5181c4954df61a7082f12f441f0867
parenteb682677f59e809d8e06c218b565aeb9723a4ad3
parent4930f4831b1547b52c5968e9307fe3d840d7fba0
Merge branch 'mptcp-do-not-block-on-subflow-socket'

Florian Westphal says:

====================
mptcp: do not block on subflow socket

This series reworks mptcp_sendmsg logic to avoid blocking on the subflow
socket.

It does so by removing the wait loop from mptcp_sendmsg_frag helper.

In order to do that, it moves prerequisites that are currently
handled in mptcp_sendmsg_frag (and cause it to wait until they are
met, e.g. frag cache refill) into the callers.

The worker can just reschedule in case no subflow socket is ready,
since it can't wait -- doing so would block other work items and
doesn't make sense anyway because we should not (re)send data
in case resources are already low.

The sendmsg path can use the existing wait logic until memory
becomes available.

Because large send requests can result in multiple mptcp_sendmsg_frag
calls from mptcp_sendmsg, we may need to restart the socket lookup in
case subflow can't accept more data or memory is low.

Doing so blocks on the mptcp socket, and existing wait handling
releases the msk lock while blocking.

Lastly, no need to use GFP_ATOMIC for extension allocation:
extend __skb_ext_alloc with gfp_t arg instead of hard-coded ATOMIC and
then relax the allocation constraints for mptcp case: those requests
occur in process context.
====================

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