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, 2 Nov 2008 14:49:41 -0800 (PST) From: Davide Libenzi <davidel@...ilserver.org> To: Olaf van der Spek <olafvdspek@...il.com> cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: epoll behaviour after running out of descriptors On Sun, 2 Nov 2008, Olaf van der Spek wrote: > On Sun, Nov 2, 2008 at 10:17 PM, Davide Libenzi <davidel@...ilserver.org> wrote: > >> Wouldn't the port space require about 20+ k connects? This issue > >> happens after 1 k. > > > > The reason for "When accept returns EMFILE, I call epoll_wait and accept > > and it returns with another EMFILE." is because your sockets-close logic > > is broken. > > It's not broken, it's designed that way. It's designed to hit the > descriptor limit and then close all sockets some time after. > > > You get an event for the listening fd, you go call accept(2) > > and in one or two passes you fill up the avail fd space, then you go back > > calling epoll_wait(), and yet back to accept(2). This w/out triggering the > > file-close-relief code (yes, you fill up 1K fds *before* 30 seconds). Of > > course you get another EMFILE. > > The second EMFILE doesn't make sense, epoll_wait shouldn't signal the > socket as ready again, right? At the time of the first EMFILE, you've filled up the fd space, but not the kernel listen backlog. Additions to the backlog, triggers new events, that you see after the first EMFILE. At a given point, the backlog is full, so no new half connections are dropped in there, so no new events are generated. Again, sleeping on (EMFILE && ET) is bad mojo, and nowhere is written that events should be generated in the EMFILE->no-EMFILE transitions. - Davide -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists