[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.1.00.0802291128560.17889@woody.linux-foundation.org>
Date: Fri, 29 Feb 2008 11:50:17 -0800 (PST)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Jakub Jelinek <jakub@...hat.com>
cc: Ollie Wild <aaw@...gle.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Michael Kerrisk <michael.kerrisk@...glemail.com>,
Andrew Morton <akpm@...ux-foundation.org>,
michael.kerrisk@...il.com, carlos@...esourcery.com,
Alan Cox <alan@...rguk.ukuu.org.uk>,
linux-kernel <linux-kernel@...r.kernel.org>, drepper@...hat.com,
mtk.manpages@...il.com
Subject: Re: [RFC/PATCH] RLIMIT_ARG_MAX
On Fri, 29 Feb 2008, Jakub Jelinek wrote:
> On Fri, Feb 29, 2008 at 11:01:38AM -0800, Ollie Wild wrote:
> >
> > This is precisely why I picked 25% as the maximum argument size ratio.
> > In practice, that 25% can easily mean 50% or more. If people want to
> > increase this, it can probably be tweaked somewhat, but switching it
> > to, say, 50% probably isn't a good idea.
>
> I think 50% would be still fine. And, ideally make that
> MAX (RLIMIT_STACK / 2, 128KB) to avoid regressions for programs which assume
> they can pass ARG_MAX args+env, even if they have say 192KB stack limit.
It would certainly be worth at least testing that as an approach.
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".
Linus
--
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/
Powered by blists - more mailing lists