]> git.baikalelectronics.ru Git - kernel.git/commit
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)
commit6f65e4c73286fb3e3af75a3811ea8be3747dc1ca
tree11c8520bff5181c4954df61a7082f12f441f0867
parentb52b408908819507f699fa7f0cb7a0e239480d3f
parent1f490550cf90413406ce37ef4545901c44e56a6b
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>