On Fri, 29 Feb 2008, Michael Kerrisk wrote:

quoted text
> On Fri, Feb 29, 2008 at 7:39 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>
> >  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?

We *do* know for sure that the relationship has always been there. At 
least in Linux, and I bet in 99% of all other Unixes too. The arguments 
simply have traditionally been counted as part of the stack size.

Or did you mean the latter part?

The fact is, we *also* know for sure that anybody that depends on 
_SC_ARG_MAX being exact has always - and will continue to be - broken. 
Again, because of not only older kernels but also because even with the 
patch in question, we don't count argument sizes exactly.

quoted text
> 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.

I do agree that we should at least make the "MAX(stacksize/4, 128k)" 
change for backwards compatibility. That is actually a potential 
regression, but it has nothing to do with a new _SC_ARG_SIZE, because 
quite frankly, it's a regression *regardless* of whether we'd expose a new 
rlimit or not!

And one of the reasons I'm so down on new resource limits is that nobody 
then has the code to actually update them. You won't see it in "ulimit -a" 
until you have a newly compiled bash that cares etc etc, so as far as I'm 
concerned, I see hat RLIMIT_ARG_MAX as nothing but a pain. It actually 
makes the code more complex, makes it work less like we and others have 
*always* worked, and doesn't even help users - quite the reverse.

I don't like unnecessary complexity. If the RLIMGI_STACK/4 check is truly 
so troublesome, let's just *remove* it, rather than add more crap and 
complexity on top of it!

Problem solved.

		Linus
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/