Messages in this thread | | | Date | Fri, 29 Feb 2008 20:49:16 +0100 | From | "Michael Kerrisk" <> | Subject | Re: [RFC/PATCH] RLIMIT_ARG_MAX |
| |
On Fri, Feb 29, 2008 at 7:39 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > > On Fri, 29 Feb 2008, Michael Kerrisk wrote: > > > > My reading of POSIX.1 (and POSIX doesn't seem very explicit on this point), is > > that the limits on argv+environ and on stack are decoupled, since POSIX > > specifies RLIMIT_STACK and sysconf(_SC_ARG_MAX) and doesn't specify any > > relationship between the two. > > I agree. And clearly there _are_ relationships and always have been, but > equally clearly they simply haven't been a big issue in practice, and > nobody really cares.
Do we know that for sure?
> Usually, _SC_ARG_MAX is just so much smaller than RLIMIT_STACK that it > makes no possible difference. Which I would actually argue we should just > continue with: just keep _SC_ARG_MAX a smallish, irrelevant constant. > > We still have to have the compile-time ARG_MAX constant (as in *real* > constant - a #define) anyway, for traditional programs, and you might as > well make sysconf(_SC_ARG_MAX) always just match ARG_MAX. > > It's not like there is likely a single user of _SC_ARG_MAX that cares.
In my initial reply, I pointed out one example where users *may* care: NPTL uses RLIMIT_STACK to determine the size of per-thread stacks. It is conceivable that users might want to set RLIMIT_STACK < 512k, and that would have the effect of lowering the amount of space for argv+eviron below what the kernel has historically guaranteed. That's an ABI change, though it's unclear whether it would impact anyone in practice.
| |