[Bugme-janitors] [Bug 10095] Kernel does not honour _ARG_MAX when computing size of argp+envp in execve'd new process image.

[bugme-daemon at bugzilla.kernel.org]

http://bugzilla.kernel.org/show_bug.cgi?id=10095





------- Comment #3 from carlos at codesourcery.com  2008-02-25 12:59 -------
Peter,

There is a real need in userspace for very-large argument passing, as proof see
the @file support added to libiberty for gcc. The @file support allows a
program to inject command line arguments into another exec'd program via a
file. It would be nice to avoid this, unfortunately, we need a way to determine
if the running kernel supports variable length argument passing.

How do we expose cool new features, like this one, to userspace?

Please see http://sourceware.org/bugzilla/show_bug.cgi?id=5786 for some
background on the issue.

What do you think about adding a new RLIMIT_ARG_MAX, and having the kernel
return the current value it has reserved as the limit?

I can then go suggest the POSIX.1 spec changes:

1. Define RLIMIT_ARG_MAX for getrlimit, as the number of bytes from
RLIMIT_STACK which are reserved for arg and env passing.

2. Reword sysconf to say "The return value of sysconf(_SC_ARG_MAX) may change
if you call setrlimit with changes to RLIMIT_ARG_MAX." Note that it already
says similar things for sysconf(_SC_OPEN_MAX).

In light of all this, I still think the kernel should provide a minimum of
MAX_ARG_PAGES * PAGE_SIZE bytes, as it did before, to comply with the sysconf
requirement that the limit not be more restrictive than the compiled in limit.

My only intent is to make it easier for userspace to use this feature. As it
stands no userspace process knows that there is more than sysconf(_SC_ARG_MAX)
available, and the new kernel fails to provide the compiled in minimum.


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.