This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/5786] sysconf(_SC_ARG_MAX) no longer accurate since Linux kernel 2.6.23
- From: "carlos at codesourcery dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 25 Feb 2008 17:13:36 -0000
- Subject: [Bug libc/5786] sysconf(_SC_ARG_MAX) no longer accurate since Linux kernel 2.6.23
- References: <20080222153833.5786.michael.kerrisk@gmail.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From carlos at codesourcery dot com 2008-02-25 17:13 -------
Subject: Re: sysconf(_SC_ARG_MAX) no longer accurate since
Linux kernel 2.6.23
michael dot kerrisk at googlemail dot com wrote:
>> This change makes _SC_ARG_MAX variable over the life of the program, simialr to
>> _SC_OPEN_MAX (after a call to setrlimit with RLIMIT_NOFILE). The standard will
>> need to be changed, as it was changed for _SC_OPEN_MAX, to say "...may return
>> different values before and after a call to..."
>
> I don't think this is true. Please read the text that I wrote for the
> man page. The limit is determined by the RLIMIT_STACK value that is
> in force **at the time of the execve()**. Thereafter, it is
> invariant.
The standard requires that the return value of sysconf(_SC_ARG_MAX)
remain invariant over the lifetime of the calling process, and execve
doesn't make a new process, instead it overlays a new process image.
Note that the pid and resource limits are inherited.
Consider the following scenario:
1. At startup the application calls sysconf(_SC_ARG_MAX) to compute how
many arguments it may pass to execve.
2. The application, in the course of running, calls setrlimit with a
lower RLIMIT_STACK.
3. The application calls execve.
Expected behaviour:
- Application has atleast sysconf(_SC_ARG_MAX) space to pass argv and
envp to the execve.
New behaviour:
- There may not be enough room to pass those parameters?
If we allow the value to change over the lifetime of a process then the
wording of the standard should be updated.
>> What happens if you have less than 512 kB of RLIMIT_STACK? A quarter of that
>> RLIMIT_STACK could be less than ARG_MAX. I would think it a kernel bug if it
>> doesn't honour providing ARG_MAX space.
>
> POSIX.1 says ARG_MAX must only be at least 4096. That's all the
> kernel must honour. I haven't actually checked whether it does honour
> that though.
That is not all the kernel must honour. The value returned by
sysconf(_SC_ARG_MAX) shall not be more restrictive than whatever value
_ARG_MAX had at compile time.
Kernel implementation:
- The kernel does not provide an initial minimum of _ARG_MAX space, see
fs/exec.c (__bprm_mm_init) where "vma->vm_start = vma->vm_end -
PAGE_SIZE;" is set. The kernel provides an initial PAGE_SIZE block
regardless of RLIMIT_STACK, unfortunately this is not enough space.
- The kernel does not maintain a minimum of _ARG_MAX space, see
fs/exec.c (get_arg_page) where "size > rlim[RLIMIT_STACK].rlim_cur / 4"
is checked. The kernel should maintain a minimum of _ARG_MAX space.
IMO these are kernel bugs in 2.6.23. Filed.
http://bugzilla.kernel.org/show_bug.cgi?id=10095
In summary:
The kernel should use the value of _ARG_MAX, as defined at kernel
compile time, as the per-process minimum number of bytes allocated for
argv and envp, regardless of the RLIMIT_STACK value.
The specification should be changed to indicate that calls to
setrlimit(RLIMIT_STACK, ...) may change the returned value of
sysconf(_SC_ARG_MAX).
Add a new resource for getrlimit called "RLIMIT_ARG_MAX" and implement
this in the kernel to return the value used by the kernel (This will
likely return "current->signal->rlim[RLIMIT_STACK].rlim_cur / 4".
Glibc will return getrlimit(RLIMIT_ARG_MAX,...) if it is available or
_ARG_MAX as the return value for sysconf(_SC_ARG_MAX).
Comments?
--
http://sourceware.org/bugzilla/show_bug.cgi?id=5786
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.