[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 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 <> 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?

    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:

    process 1:
    leaf fd
    leaf fd 2
    leaf fd 3
    leaf fd 4

    process 2:

    While the attack happens inside a single process.

    Indeed, if you had a _per_process_ watcher limit, you would stop the
    attack working while not breaking at least postfix and apache. I'm not
    sure what Java's doing under the hood, I have a feeling it's more

    But most of all a way of detecting between a leaf fd and an epoll
    watcher fd in epoll_ctl and doing deeper tests if it's an epoll watcher
    that's being added would stop the attack.


     \ /
      Last update: 2009-01-28 22:03    [W:0.027 / U:20.572 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site