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: "michael dot kerrisk at googlemail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 26 Feb 2008 09:53:38 -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 michael dot kerrisk at googlemail dot com 2008-02-26 09:53 -------
Subject: Re: sysconf(_SC_ARG_MAX) no longer accurate since Linux kernel 2.6.23
On 25 Feb 2008 17:13:36 -0000, carlos at codesourcery dot com
<sourceware-bugzilla@sourceware.org> wrote:
>
> ------- 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.
Doh! Yes, of course you are right!
> 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?
Agreed.
> If we allow the value to change over the lifetime of a process then the
> wording of the standard should be updated.
Well, I suppose it could be worth trying to se whetehr that change
would make it through the standards process/
> >> 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.
Yes, but I'm not sure that we can say that the kernel is advertising a
particular value for ARG_MAX. Yes, there is a definition in
include/linux/limits.h, but it was never used in the kernel sources as
far as I can see. Being weaselly, I believe the header file could
equally be amended to say
#define ARG_MAX 4096
> - 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
Ahh -- only just read that now. I see Peter saying some of the same
things as me, but I don't know that I agree with all he says.
> 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.
As I say, the kernel folk could just redefine ARG_MAX as 4096.
> The specification should be changed to indicate that calls to
> setrlimit(RLIMIT_STACK, ...) may change the returned value of
> sysconf(_SC_ARG_MAX).
As I think about this more, it seems ugly. The real problem is that
RLIMIT_STACK should probably not have been overloaded to also e used
for controlling ARG_MAX. That's a bit of a hack, and I'd suspect that
the POSIX folks would (rightly) reject it.
> 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".
Is your meaning here, that the RLIMIT_ARG_MAX limit would be
read-only, returning a value based on RLIMIT_STACK? That is not
consistent with the semantics of other rlimits.
Cheers,
Michael
> 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 reported the bug, or are watching the reporter.
>
--
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.