Re: [RFC/PATCH] RLIMIT_ARG_MAX

On Fri, Feb 29, 2008 at 9:07 PM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:


On Fri, 29 Feb 2008, Michael Kerrisk wrote:

> On Fri, Feb 29, 2008 at 7:39 PM, Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxxx> 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?

I meant: do we know for sure that no one really cares?

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.

Good -- because that's probably the most important point, IMO.

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!

Agreed.

The new rlimit is primarily for the (supposed) applications that care
about knowing (at least approximately) what _SC_ARG_MAX is. I raised
the initial bug report against glibc because applications can no
longer (post 2.6.23) do this, but I haven't done the investigation
about how many applications actually care.

Cheers,

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

Relevant Pages

  • Re: Honestly Curious
    ... Who cares? ... Spotlight is the answer here. ... regards to it's limitation of the users options of moving applications. ... It's not the operating system function to limit my ability to "lose" ...
    (comp.sys.mac.advocacy)
  • Re: Honestly Curious
    ... Who cares? ... Spotlight is the answer here. ... But don't try to apologize for Windows shortcomings with regards to it's limitation of the users options of moving applications. ...
    (comp.sys.mac.advocacy)
  • Re: Tuning windchimes with a Mac
    ... An obvious case of PEBKAC. ... Good luck using an OS and applications that no one maintains or cares about any more. ...
    (comp.sys.mac.apps)
  • Re: Tuning windchimes with a Mac
    ... "Good luck using an OS and applications that no one maintains or cares ... Symantec updated their virus defs for version 6 and 7 on November 1st. ...
    (comp.sys.mac.apps)
  • Re: Tuning windchimes with a Mac
    ... "Good luck using an OS and applications that no one maintains or cares ... Symantec updated their virus defs for version 6 and 7 on November 1st. ...
    (comp.sys.mac.apps)