lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 17 May 2020 12:36:41 -0700 (PDT) From: David Miller <davem@...emloft.net> To: fw@...len.de Cc: netdev@...r.kernel.org, pabeni@...hat.com, mathew.j.martineau@...ux.intel.com, matthieu.baerts@...sares.net Subject: Re: [PATCH net-next 0/7] mptcp: do not block on subflow socket From: Florian Westphal <fw@...len.de> Date: Sat, 16 May 2020 10:46:16 +0200 > 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. Series applied, thanks Florian.
Powered by blists - more mailing lists