linux-kernel - Re: [patch 016/104] epoll: introduce resource usage limits

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.0901272135400.20262@alien.or.mcafeemobile.com>
Date:	Tue, 27 Jan 2009 22:38:22 -0800 (PST)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Greg KH <gregkh@...e.de>
cc:	Bron Gondwana <brong@...tmail.fm>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	stable@...nel.org, Justin Forbes <jmforbes@...uxtx.org>,
	Zwane Mwaikambo <zwane@....linux.org.uk>,
	Theodore Ts'o <tytso@....edu>,
	Randy Dunlap <rdunlap@...otime.net>,
	Dave Jones <davej@...hat.com>,
	Chuck Wolber <chuckw@...ntumlinux.com>
Subject: Re: [patch 016/104] epoll: introduce resource usage limits

On Tue, 27 Jan 2009, 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.

Do you really want to add that crud just to monitor a value? That cost 
absolutely zero (in terms of pre-allocated resources) to bump up?
Is not like, that you want to keep the bound value close to the current 
peak because using an even higher value could result in pre-allocated 
resource waste. No because I could understand if rising such number to 
higher-than-needed values could result in waste of resources, so you want 
to monitor it to keep it as close as possible to the peak. But this is not 
the case.
So today we have three groups of users:

- Users that have been hit by the limit
  * Those have probably bumped the value up to the wazzoo.

- Unaware users with machines having potential of hitting the current limit
  * Those, monitor or not, being unaware, they won't notice it until hits. 
    And since rising it costs zero, they'd likely prefer to bump it to the 
    stars instead of monitoring an incrementing by small steps.
  * Applying a lomem-dependent max_instances default value like the two 
    lines patch I posted, is probably the best choice even for stable.

- Unaware users with low-load machines
  * Those won't even notice it.

The default value can be rised, bound to lomem sizes. I see no problems in 
there. Or, like Willy said, make (for -stable) the default unlimited, and 
let sysadmins to put the bounds if they feel the DoS can apply to them.




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