lkml.org 
[lkml]   [2009]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 016/104] epoll: introduce resource usage limits
    On Wed, 28 Jan 2009, Willy Tarreau wrote:

    > On Tue, Jan 27, 2009 at 09:26:30PM -0800, Greg KH wrote:
    > > On Tue, Jan 27, 2009 at 08:10:41PM -0800, Davide Libenzi wrote:
    > > > In my servers, I know if they are going to be loaded, and I bump NFILES
    > > > (and a few other things) to the correct place. Since many of those
    > > > limits do not actually pre-allocate any resource, I don't need to wait and
    > > > monitor the values, before taking proper action.
    > >
    > > But what about people who want to know what the current usages are, so
    > > that they _can_ monitor things and adjust them on the fly if things are
    > > about to go boom?
    > >
    > > I see no reason why we can't leave the value where it is today, and add
    > > the ability to both turn the limits off entirely, and also report our
    > > current usage. That keeps the DOS from happening on "default" systems,
    > > and lets admins have an idea if they need to bump up the values on their
    > > systems as well.
    > >
    > > I don't understand your objection to allowing the usage to be monitored.
    >
    > Agreed. If sysadmins get trapped by the upgrade, the fix for an
    > hypotethical DoS is a 100%-certain DoS by itself. The general sense
    > that "if it's not broken, don't fix it" applies here as well. The
    > server's sysadmin should not be bothered by a security upgrade (anyway,
    > after a few minutes of havoc in prod, he will revert to previous version
    > without trying to understand any further). But the campus sysadmin having
    > trouble with local users already spends a lot of time tweaking limits.
    > Now we offer them a new limit they can tune, they'll happily use it.
    > Anyway, even at 128 they'll probably lower it down a lot. So basically
    > we're with a medium value which does not fit any usage.

    You know, it's not me that decides what goes of certain trees or not ;)
    I've been pinged about the problem, and a patch was sent with values that
    seemed appropriate for typical epoll usages. Epoll is a multiplexing
    interface, so the thought was that not too many instances were lingering
    around. Probably the default max_instances should have been made lomem
    dependent like max_user_watches in the first place, leading to higher
    max_instances values, with respect of the potential DoS.



    - Davide




    \
     
     \ /
      Last update: 2009-01-28 06:51    [W:4.411 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site