lkml.org 
[lkml]   [2008]   [Feb]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC/PATCH] RLIMIT_ARG_MAX


On Fri, 29 Feb 2008, Michael Kerrisk wrote:

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

> 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


\
 
 \ /
  Last update: 2008-02-29 21:15    [W:0.070 / U:0.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site