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 linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 07 Jun 2020 09:05:03 -0600 From: Leif Hedstrom <lhedstrom@...le.com> To: Florian Westphal <fw@...len.de> Cc: Eric Dumazet <eric.dumazet@...il.com>, Christoph Paasch <christoph.paasch@...il.com>, Julian Anastasov <ja@....bg>, Wayne Badger <badger@...oo-inc.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org> Subject: Re: TCP_DEFER_ACCEPT wakes up without data > On Jun 7, 2020, at 04:01, Florian Westphal <fw@...len.de> wrote: > > Eric Dumazet <eric.dumazet@...il.com> wrote: >>> Sure! TCP_DEFER_ACCEPT delays the creation of the socket until data >>> has been sent by the client *or* the specified time has expired upon >>> which a last SYN/ACK is sent and if the client replies with an ACK the >>> socket will be created and presented to the accept()-call. In the >>> latter case it means that the app gets a socket that does not have any >>> data to be read - which goes against the intention of TCP_DEFER_ACCEPT >>> (man-page says: "Allow a listener to be awakened only when data >>> arrives on the socket."). >>> >>> In the original thread the proposal was to kill the connection with a >>> TCP-RST when the specified timeout expired (after the final SYN/ACK). >>> >>> Thus, my question in my first email whether there is a specific reason >>> to not do this. >>> >>> API-breakage does not seem to me to be a concern here. Apps that are >>> setting DEFER_ACCEPT probably would not expect to get a socket that >>> does not have data to read. >> >> Thanks for the summary ;) >> >> I disagree. >> >> A server might have two modes : >> >> 1) A fast path, expecting data from user in a small amount of time, from peers not too far away. >> >> 2) A slow path, for clients far away. Server can implement strategies to control number of sockets >> that have been accepted() but not yet active (no data yet received). > > So we can't change DEFER_ACCEPT behaviour. > Any objections to adding TCP_DEFER_ACCEPT2 with the behaviour outlined > by Christoph? I think that would be useful, although ideally a better, more descriptive name ? Cheers, — Leif
Powered by blists - more mailing lists