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: <1233125523.19204.1297144311@webmail.messagingengine.com>
Date:	Wed, 28 Jan 2009 17:52:03 +1100
From:	"Bron Gondwana" <brong@...tmail.fm>
To:	"Davide Libenzi" <davidel@...ilserver.org>,
	"Greg KH" <gregkh@...e.de>
Cc:	"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 22:38 -0800, "Davide Libenzi" <davidel@...ilserver.org> wrote:
> 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.

Yeah, pretty much.  But we've bumped things up to the wazzoo before
only to discover that our usage crept up there (file-max of 300,000
being a case on one machine recently.  Appears you can hit that
pretty easily when you change from smaller machines to 32Gb memory

That's why the first time we hit file-max, we added a check into
our monitoring system so we get warned before we hit it.  Any
fixed limit, I'd want one of these.  Makes me sleep much better
(literally, the bloody things SMS me if checks start failing)

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

True.  After they spend a day and a half figuring out what's causing
them out-of-files errors.  They swear a lot and do the wazzoo thing.

>   * Applying a lomem-dependent max_instances default value like the two 
>     lines patch I posted, is probably the best choice even for stable.

Would probably still make me sad, since these are 32 bit machines.  Given
that 150 or so seems to be the steady state on the mxes, I wouldn't want
to know what it gets up to under a spam run.  Probably close to 1000, since
that's what we limit smtpds at.

[brong@mx1 ~]$ ps ax | grep smtpd | wc -l
122
[brong@mx1 ~]$ cat /proc/sys/fs/epoll/limits 
0	159	107	1451	4096	266555

Yeah, near enough.  159 is the interesting value here (old version of limits
file, the fields are in a different order)

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

No, until their usage pattern changes and they become one of the middle bunch.

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

I'd be happy with a default of unlimited (my patch 2 plus a couple of zero
defaults would do it)

Bron ( and to think I was going to suggest a patch that would check the value
       you wrote to max_user_* to ensure it wasn't less than the current
       highest user so you didn't accidentally munt your box ;) )
-- 
  Bron Gondwana
  brong@...tmail.fm

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