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]

Date:	Wed, 28 Jan 2009 07:59:12 +0100
From:	Willy Tarreau <w@....eu>
To:	Davide Libenzi <davidel@...ilserver.org>
Cc:	Greg KH <gregkh@...e.de>, 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, Jan 27, 2009 at 10:36:25PM -0800, Davide Libenzi wrote:
> On Wed, 28 Jan 2009, Willy Tarreau wrote:
> 
> > Davide, I know it's not you who decide. I mean, one patch was proposed
> > with one arbitrary limit. I've seen it in advance too and I too thought
> > it would be more than enough. Now people are reporting breakage from
> > common applications which work in a funny way (I think that using epoll
> > to poll for one single FD in a multi-process architecture can be called
> > funny). But those people are not expected to understand the internals,
> > and most likely their application's behaviour might not be more precisely
> > described than "it broke since upgrade to 2.6.27.13".
> > 
> > I think we should accept the fact that the fix is causing problems
> > for people while it was not expected to do so. One of the solutions
> > would be to increase the arbitrary ratio from 1% to more than that,
> > but it will still break big setups. Another solution is to accept
> > that the patch provides a tunable that admins might act on to stop
> > local users' nasty activities if required, but leave the limit off
> > by default. And I think that's a saner approach, especially for a
> > stable series.
> 
> Absolutely. There is no 100% fit solution here. Heck, if we want to remove 
> the tunable altogether I'm the happiest one, but the problem with the 
> pinneable memory is there.

we shouldn't remove the tunable IMHO.

> We can decide to remove the caps in the default setup, and leave default 
> setups open to the DoS. I've no problem with that (and, as we know, I 
> don't decide policies).
> Then sysadmins of multiuser systems will have to enforce the caps 
> themselves in order to limit the potential DoS. This is probably a good 
> strategy for -stable anyway.

Yes, this is what I'd like to see in -stable too. I'm currently contacting
a few people I suggested to upgrade to 2.6.27.13 to warn them about the
issue.

Regards,
Willy

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