Re: [RFC/PATCH] RLIMIT_ARG_MAX

["Michael Kerrisk" <michael.kerrisk@googlemail.com>]

[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.

Cheers,

Michael