linux-kernel - Re: epoll behaviour after running out of descriptors

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 2 Nov 2008 10:25:27 -0800 (PST)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Olaf van der Spek <olafvdspek@...il.com>
cc:	linux-kernel@...r.kernel.org
Subject: Re: epoll behaviour after running out of descriptors

On Sat, 1 Nov 2008, Olaf van der Spek wrote:

> Hi,
> 
> I noticed some strange behaviour of epoll after running out of descriptors.
> I've registered a listen socket to epoll with edge triggering. On the
> client-side I use an app that simply keeps opening connections.
> When accept returns EMFILE, I call epoll_wait and accept and it
> returns with another EMFILE.
> This happens 10 times or so, after that epoll_wait no longer returns
> with the listen socket ready.
> I then close all file descriptors, but epoll_wait will still not return.
> So my question is, why does it 'only' happen 10 times and what is the
> expected behaviour?
> And how should an app handle this?
> 
> The example in the epoll man page doesn't seem to handle this.
> 
> An idea I had was for epoll_wait to only return with accept / EMFILE
> once. Then after a descriptor becomes available, epoll_wait would
> return again.
> 
> See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502901
> 
> Hi,
> 
> I've written a web app that should be able to handle a lot of new
> connections per second (1000+). On multiple servers I've hit a bug.
> After running out of descriptors, then closing descriptors, epoll_wait
> doesn't return anymore for the listen socket.
> I've attached code to reproduce the issue. And an strace log. Even
> before closing the descriptors you see epoll_wait already stops returning.

A bug? For starters, epoll_wait does NOT create new files, so no EMFILE 
can come out from there.
You are saturating the port space, and your whole code logic is rather (at 
least) buggy. Try a `netstat -n -t | grep TIME_WAIT | wc -l`



- 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/