Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751700AbVIZRfK (ORCPT ); Mon, 26 Sep 2005 13:35:10 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751702AbVIZRfK (ORCPT ); Mon, 26 Sep 2005 13:35:10 -0400 Received: from [212.76.86.33] ([212.76.86.33]:5636 "EHLO raad.intranet") by vger.kernel.org with ESMTP id S1751700AbVIZRfJ (ORCPT ); Mon, 26 Sep 2005 13:35:09 -0400 From: Al Boldi To: Neil Horman Subject: Re: Resource limits Date: Mon, 26 Sep 2005 20:32:14 +0300 User-Agent: KMail/1.5 Cc: Rik van Riel , linux-kernel@vger.kernel.org References: <200509251712.42302.a1426z@gawab.com> <200509261718.17658.a1426z@gawab.com> <20050926155644.GC2100@hmsreliant.homelinux.net> In-Reply-To: <20050926155644.GC2100@hmsreliant.homelinux.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509262032.14613.a1426z@gawab.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1477 Lines: 42 Neil Horman wrote: > On Mon, Sep 26, 2005 at 05:18:17PM +0300, Al Boldi wrote: > > Rik van Riel wrote: > > > On Sun, 25 Sep 2005, Al Boldi wrote: > > > > Resource limits in Linux, when available, are currently very > > > > limited. > > > > > > > > i.e.: > > > > Too many process forks and your system may crash. > > > > This can be capped with threads-max, but may lead you into a > > > > lock-out. > > > > > > > > What is needed is a soft, hard, and a special emergency limit that > > > > would allow you to use the resource for a limited time to circumvent > > > > a lock-out. > > > > > > > > Would this be difficult to implement? > > > > > > How would you reclaim the resource after that limited time is > > > over ? Kill processes? > > > > That's one way, but really, the issue needs some deep thought. > > Leaving Linux exposed to a lock-out is rather frightening. > > What exactly is it that you're worried about here? Do you have a > particular concern that a process won't be able to fork or create a > thread? Resources that can be allocated to user space processes always > run the risk that their allocation will not succede. Its up to the > application to deal with that. Think about a DoS attack. Thanks! -- Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/