This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


------- 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]