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
| ||
|
Message-ID: <20071027093424.GA31329@schmorp.de> Date: Sat, 27 Oct 2007 11:34:24 +0200 From: Marc Lehmann <schmorp@...morp.de> To: Eric Dumazet <dada1@...mosbay.com> Cc: Marc Lehmann <linux-kernel@....eu>, linux-kernel@...r.kernel.org, Davide Libenzi <davidel@...ilserver.org> Subject: Re: epoll design problems with common fork/exec patterns On Sat, Oct 27, 2007 at 11:22:25AM +0200, Eric Dumazet <dada1@...mosbay.com> wrote: > >Well, it behaves like documented, which is the problem. You admit you > >don't understand the problem or the documentation, so again, no need to > >insult me. > > Hum... I will update my english vocabulary and mark "missed" as an insult. Well, ignoring my arguments by claiming I lack understanding is an insult, as you didn't take my arguments at face value but declassified them by attacking my person. > I have no problem with epoll nor its documentation. Thats fine for you. But I have, at least, with epoll, as the documented and observed behaviour makes epoll unusable as a general event loop replacement. > It doesnt on every kernels I had played with. And I played with *lot* of > kernels you know. No, I don't know that. And so far you only said you used fork+exec, not close in between, so maybe the playing you did was not related to this problem? I also played with a lot of kernels, but for epoll specifically, I played with 2.6.21-2-amd64 and 2.6.22-1-amd64, both from debian unstable with no customisations. > If such a bug exists on your kernel, please fill a complete bug report, > giving details. As this behaviour is clearly documented in the epoll manpage, why do you think it is a bug? I think its fairly bad, but at least tis documented as the behaviour it should be: Q6 Will the close of an fd cause it to be removed from all epoll sets automatically? A6 Yes. As such filing, a bug report for behaviour which isn't in fact a bug would be counterproductive. My goal in my mail was to find out if there are work arounds for this peculiar behaviour (Or inspire discussion on this behaviour). Of course, one can create big programs using epoll to their advantage. I never claimed otherwise. But as a general event loop replacement (i.e. outside of controleld environments), epoll does not currently qualify, as I would have to control an awful lot of code (think of an perl module interfacing to epoll: you would not have to control all third-party modules that might interfere with fork+close+exec. This is very common in scripting languages). -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / pcg@...f.com -=====/_/_//_/\_,_/ /_/\_\ - 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