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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 27 Jan 2009 22:36:25 -0800 (PST)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Willy Tarreau <w@....eu>
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 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 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.



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