[Bug libc/5786] sysconf(_SC_ARG_MAX) no longer accurate since Linux kernel 2.6.23

["michael dot kerrisk at googlemail dot com" <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.