linux-kernel - Re: [PATCH 1/3] epoll: increase default max_user

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]

Message-ID: <alpine.DEB.1.10.0901281538400.21401@alien.or.mcafeemobile.com>
Date:	Wed, 28 Jan 2009 15:51:39 -0800 (PST)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Bron Gondwana <brong@...tmail.fm>
cc:	Vegard Nossum <vegard.nossum@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Greg KH <gregkh@...e.de>
Subject: Re: [PATCH 1/3] epoll: increase default max_user_instances to 1024

On Thu, 29 Jan 2009, Bron Gondwana wrote:

> On Wed, Jan 28, 2009 at 08:52:51AM -0800, Davide Libenzi wrote:
> > On Wed, 28 Jan 2009, Vegard Nossum wrote:
> > 
> > > On Wed, Jan 28, 2009 at 6:32 AM, Bron Gondwana <brong@...tmail.fm> wrote:
> > > > That's clearly not happening here - so it seems that maybe our "happy
> > > > medium" is actually in closer inspection of what's going on rather than
> > > > a blanket low N to keep N^2 down.
> > > 
> > > Mh, could another solution to this all be to limit the number times
> > > you can add a single epoll descriptor to another descriptor's set?
> > 
> > In the example that was posted, a single fd was added a single time inside 
> > the other 1000+ fds. Epoll already has detection for too long chains and 
> > closed loops, but you can't put those in the fast path. And epoll_ctl() is 
> > one of those.
> 
> Not even if you're adding an epoll watcher inside another epoll watcher?

Adding an epoll fd inside another epoll fd is perfectly legal. It would
kinda suck if epoll itself wouldn't expose a pollable interface too.



> The problem I have here is that "a single fd was added a single time
> inside the other 1000+ fds" is different behaviour to the daemons out
> there.  They're pretty much all using flat layouts:

Yes, that is not what programs normally do. Most of the times you have 
nesting level equal zero, although we've seen recently that the 
epoll-being-pollable feature (hence nesting) is used too. Say you have two 
(or more) libraries, each own monitoring different things, and each own 
with its own wait+dispatch loop. If these libraries didn't have a chance 
to expose a pollable fd, you'd have to run their wait+dispatch loop in 
seaprate threads. Whereas epoll being itself pollable allows you to:

	epoll_wait(lib1_fd, lib2_fd)
	if (ready(lib1_fd))
		lib1_dispatch()
	if (ready(lib2_fd))
		lib2_dispatch()

This is pretty powerful, although needs care for wakeups and poll nested 
calls.



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