Re: [RFC/PATCH] RLIMIT_ARG_MAX

Peter Zijlstra
2008-02-29T17:14:48Z

On Fri, 2008-02-29 at 17:58 +0100, Michael Kerrisk wrote:
> [Adding Ulrich D to the CC]
>
> On Fri, Feb 29, 2008 at 5:05 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> >
> > On Wed, 27 Feb 2008, Peter Zijlstra wrote:
> > >
> > > Currently these arrays are considered part of the stack, and
> > > RLIMIT_STACK includes them. However POSIX does not specify it must be
> > > so.
> >
> > What's the real advantage of this? I'm not seeing it. Just an extra
> > complexity "niceness" that nobody can rely on anyway since it's not even
> > specified, and older kernels won't do it.
>
> The advantages are the following:
>
> 1. We don't break the ABI. in 2.6.23, RLIMIT_STACK acquired an
> additional semantic: RLIMIT_STACK/4 specified the size for
> argv+environ. aaw@google.com added this feature to allow processes to
> have much larger argument lists. However, if the user sets
> RLIMIT_STACK to less than 512k, then the amount of space for
> argv+environ falls below the space guaranteed by kernel 2.6.22 and
> earlier. (Older kernels guaranteed at least 128k for argv+environ.)
> Manipulating RLIMIT_STACK did not previously have this effect. (One
> place this matters is with NPTL, where, if RLIMIT_STACK is set to
> anything other than unlimited, then it is used as the default stack
> size when creating new threads. When creating many threads, it may
> well be desirable to set RLIMIT_STACK to a value lower than 512k.)
>
> While the new functionality provided by aaw@google.com's work is
> useful, RLIMIT_STACK really should not have been overloaded with a
> second meaning, since it is no longer possible to control stack size
> without also changing the limit on argv+environ space. Hence the
> proposal of a new resource limit.
>
> 2. It provides a sane mechanism for an application to determine the
> space available for argv+environ. Formerly this space was an
> invariant, advertised via sysconf(_SC_ARG_MAX).
>
> 3. The implementation details about stack size and size/location of
> argv+environ can be decoupled.

You fail to mention that <23 will still fault the first time it tries to
grow the stack when you set rlimit_stack to 128k and actually supply
128k of env+arg.