Bug#234139: libc doc vs manpages disagreement
At Sun, 22 Feb 2004 14:50:43 -0500,
Marek Habersack wrote:
> On Sun, Feb 22, 2004 at 12:55:38PM +0100, Martin Schulze scribbled:
> > Marek Habersack wrote:
> > > Hey,
> > >
> > > I've just noticed that the two sources disagree on the units used for the
> > > RLIMIT_RSS resource. libc docs claim that all the memory limits are
> > > expressed in bytes while setrlimit(2) claims RLIMIT_RSS size is in pages
> > > (which bash's ulimit seems to agree with).
> > > The kernel seems to agree with the libc docs. So, should I file a bug
> > > against the manpages or the libc docs?
> >
> > Manual pages from the man-pages project/package document the standard,
> > not primarily its implementation from random entities, even if the
> > entity in question may be the Free Software Foundation.
> The thing is that RLIMIT_RSS is not documented by any standard (unless you
> count the *BSD manpages[1,2,3] as one). I have looked closely at the 2.4 kernel
> sources and it seems that linux does it the other way around and, indeed,
> the RLIMIT_RSS is in pages (as evidenced by [4,5] - PAGE_SHIFT is a macro
> that defines the number of bits by which a value must be left/right shifted
> in order to obtain memory size in pages/bytes respectively. It's
> architecture-specific).
In 2.4 - yeah, exactly that's true. But look at 2.6. Rik's new patch
which is not still adopted (afaik) in linus tree is byte based. And
RLIMIT_RSS is derived from BSD - and at least BSD and AIX use it as in
bytes. This means that kernel 2.4 is not compatible with generic
behavior - it's only 2.4 rule. I think this is kernel 2.4 potential
incompatibility. Well, we cannot say this "in page" is kernel bug -
because RLIMIT_RSS is not defined in official documents.
> > However, if you can prove, by quoting the source, that libc behaves
> > different than what is written in our manpages, I'm willing to add
> > a note and pass it upstream, who may reject it, though.
> The comments in the bits/resource.h file confirm that libc thinks the
> amount is in bytes and I can't find any place where libc converts the value
> passed by the user to pages. Therefore, if somebody believes the libc
> docs/headers/sources, they will end up passing an incorrect value for the
> limit to the kernel (not that it matters on kernel v2.6)
>
> I've already reassigned Bug#234139 to libc6 and I'm Cc'ing this mail to the
> BTS since it corrects the mistake I made in the bug report.
If you want to dig more, the manual should write this topic as "2.6
has no RLIMIT_RSS, and 2.4 in page is linux specific behavior".
As debian glibc maintainer point of view, this RLIMIT_RSS is affected
only on linux 2.4 and madvise() with MADVISE_WILLNEED flag. I wonder
this topic should be really written in GLIBC manual pages. Glibc is
primarily used in linux based systems, but not only for linux but also
hurd and so on.
So if there are any chances to modify glibc manual, the description
should be add as "implementation dependent" so that I still think
kernel 2.4 way is bad and should be corrected (however such chance
will never come, as you know).
Regards,
-- gotom
Reply to: