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: 23 Feb 2008 07:52:08 -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-23 07:52 -------
Subject: Re: sysconf(_SC_ARG_MAX) no longer accurate since Linux kernel 2.6.23
On 23 Feb 2008 00:28:12 -0000, carlos at codesourcery dot com
<sourceware-bugzilla@sourceware.org> wrote:
>
> ------- Additional Comments From carlos at codesourcery dot com 2008-02-23 00:28 -------
> Interesting change, this is nice for programs that don't use libiberty's @file
> support.
>
> 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.
> We can immediately add support for calling getrlimit to compute the result of
> sysconf(_SC_ARG_MAX), conditional on `__LINUX_KERNEL_VERSION >= 0x020617' (>=
> 2.6.23) i.e. the minimum kernel version supported by this glibc is 2.6.23.
> Otherwise sysconf(_SC_ARM_MAX) must continue to return ARG_MAX, less than
> accurate, but still correct.
>
> The alternative is to add a new RLIMIT_* resource. Glibc may call getrlimit to
> see if that is set (the kernel would take care to compute the right value),
> return that for sysconf(_SC_ARG_MAX), otherwise ARG_MAX. This code would be
> enabled if you were building against headers that defined the new RLIMIT_* resource.
>
> 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.
> Are you interested in helping implement this change in glibc?
>
> Are you working with someone on the kernel side?
I'm the man-pages maintainer. While I'd like to help, three weeks ago
I became a father, and will have very few available cycles for the
next 6 weeks or more. What I do have will be entirely given over to
man pages. From April or so, I'd have time to help -- but I'd guess
you want to do things faster.
Cheers,
Michael
--
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.