Yeah, I do see the point of wanting slop, but maybe the right thing to do
is simply to just not make the slop be 75% of it all ;)
The thing is, RLIMIT_STACK has never been "exact" in the first place (ie
it has *always* contained the argument and environment as a part of it),
and that is really traditional behaviour even outside of Linux.
And I seriously doubt that RLIMIT_ARG_MAX really buys people anything
truly wonderful, and it definitely adds just another thing you can screw
up and make the system just behave differently depending on a config value
that doesn't even matter to the kernel. In fact, even with that patch,
it's *still* not going to handle the difference between the actual string
space and the pointers themselves, or even all the other setup stuff that
the binary loaders will put on the stack.
So it's not *going* to be exact even with RLIMIT_ARG_MAX, because it's
going to have all those other issues to contend with - on a 64-bit
architecture, the argument _pointers_ are often within an order of
magnitude of the argument strings themselves, and I don't think your patch
counted them as part of the argument/environemnt size (I was too lazy to
check the sources, but I'm pretty sure argv/env_start/end is just the
string space, not the pointers).
So rather than introduce a new thing that is not going to be trustworthy
anyway, I'd much rather just remove the limit entirely.
Also, it all boils down to the fact that the whole argument is utter crap:
If the resource limits change, then it makes not a whit of a difference
whether _SC_ARG_MAX changes or not, because it's not going to reflect
reality. So you might as well just continue to give the value we've always
given (128k? I don't remember). Because it's not going to be the "real"
value *anyway*.
This whole argument seems pointless. Has anybody ever really cared? Why
not just keep _SC_ARG_MAX at the old (small) limit, and then the fact that
99% of all programs won't even care, and that they can actually use much
larger limits in real life is just gravy.
A *good* implementation would generally just do the execve() with the
maximal arguments, and only bother to see "oh, maybe I can split it up" if
it returns ENOMEM or whatever it does.
So I don't see the practical value here - _SC_ARG_MAX is not worth having
another tweaking value for that people will just always get wrogn anyway
because there is no right answer (except "I don't want my stack to grow
too large" where it's just one of the relevant things)
Linus
--
