[lkml]   [2009]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/3] epoll: increase default max_user_instances to 1024
On Wed, Jan 28, 2009 at 10:16:41AM +0000, Alan Cox wrote:
> > It's really simple. A kernel upgrade in a -stable series point release
> > broke a rational user-space setup. If you don't want to adjust the
> You can just as equally load the description the other way:

Only if you're ignoring reality.

> "A kernel upgrade in a -stable series point release fixed a security DoS"

Alan, that's a complete load of bollocks. It broke common configurations
of java, postfix and apache on real-world machines, causing significant
actual denials of service in previously reliable configurations.

How about "A kernel upgrade in a -stable series replaced one potential
DoS with another DoS and provided a tunable knob to select which DoS you
would prefer, defaulting to the opposite of the previous behaviour"

> Which is not to say that a smarter limit isn't needed.

Yeah, I have an idea about that, but I need to see if it's actually
viable within the code. The DoS works by creating epoll descriptors
watching other epoll descriptors, which strikes me as a much less
real-world actual use pattern than a bunch of separate daemons with an
epoll watcher each.

If it's possible to count watches only if they're added to another epoll
instance, then we'd have a metric that still catches the N^2 attack, but
doesn't interact with the common non-attacky use-case.

I'd be much happier if we could remove the dichotomy of "allow the DoS
or live with a highly crippled epoll implementation until some of the
biggest daemons out there change their usage patterns" (thinking
particularly of java 1.6 and apache here. Largish postfix installations
are much rarer)


 \ /
  Last update: 2009-01-28 12:01    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean