Re: [RFC/PATCH] RLIMIT_ARG_MAX

From: "Ollie Wild" <aaw@google.com>
To: "Linus Torvalds" <torvalds@linux-foundation.org>
Cc: "Jakub Jelinek" <jakub@redhat.com>,
	"Peter Zijlstra" <a.p.zijlstra@chello.nl>,
	"Michael Kerrisk" <michael.kerrisk@googlemail.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	michael.kerrisk@gmail.com, carlos@codesourcery.com,
	"Alan Cox" <alan@lxorguk.ukuu.org.uk>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	drepper@redhat.com, mtk.manpages@gmail.com
Subject: Re: [RFC/PATCH] RLIMIT_ARG_MAX
Date: Fri, 29 Feb 2008 12:03:40 -0800	[thread overview]
Message-ID: <65dd6fd50802291203g5c183b49mb2717e1cd9f691b5@mail.gmail.com> (raw)
In-Reply-To: <alpine.LFD.1.00.0802291128560.17889@woody.linux-foundation.org>

On Fri, Feb 29, 2008 at 11:50 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Another thing we could decide to do is to just check the size of the stack
> that is left at the end of all the stack setup code, and just say "if it's
> less than X bytes, just return ENOMEM rather than set up a process with a
> really unusably small stack".

What would be a reasonable value, though?  Whereas argument space is
static and known at process execution time, required stack space is
program dependent.  If the program is going to crash, I'd rather it do
so at exec time.  Otherwise, we end up with corrupted files, partially
committed database transactions, and so forth.  I'd rather error on
the side of small argument space.

In the common situation, a 25% argument allocation is vastly larger
than the pre-2.6.23 limit.  We're really only talking about cases
where the limits have been set to unusually small values.  I'd be
interested in hearing from people that do this in practice.  Why do
they do this?  What are their expectations?

Ollie