From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16582 invoked by alias); 23 Feb 2008 07:52:47 -0000 Received: (qmail 16494 invoked by alias); 23 Feb 2008 07:52:08 -0000 Date: Sat, 23 Feb 2008 07:52:00 -0000 Message-ID: <20080223075208.16493.qmail@sourceware.org> From: "michael dot kerrisk at googlemail dot com" To: glibc-bugs@sources.redhat.com In-Reply-To: <20080222153833.5786.michael.kerrisk@gmail.com> References: <20080222153833.5786.michael.kerrisk@gmail.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug libc/5786] sysconf(_SC_ARG_MAX) no longer accurate since Linux kernel 2.6.23 X-Bugzilla-Reason: CC Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2008-02/txt/msg00105.txt.bz2 ------- 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 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.