Messages in this thread | | | Date | Fri, 29 Feb 2008 17:58:52 +0100 | From | "Michael Kerrisk" <> | Subject | Re: [RFC/PATCH] RLIMIT_ARG_MAX |
| |
[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
| |