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

[Carlos O'Donell <carlos at codesourcery dot com>]

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?