Re: setrlimit and RLIM_INFINITY causing fsck failure, 2.4.18

Peter Hartley
2002-03-20T10:35:54Z

Theodore Tso wrote:
> On Tue, Mar 19, 2002 at 05:45:24PM -0000, Peter Hartley wrote:
> > * glibc knows nothing about the new unsigned limits, because
> > it's compiled against 2.2 headers. So it clips the limit
> > value to 0x7FFFFFFF to "correct" it before calling the
> > setrlimit syscall. This is IMO still the Right Thing,
> > because it's trying to call the old syscall as if to run
> > a new program on a 2.2 kernel.
>
> Unfortunately, all of my testing was done under systems where the
> glibc was already compiled under 2.4 headers, so I didn't realize that
> glibc would try to be "helpful" and correct the limit used by rlimit.
> (In other words, the e2fsprogs workaround was only worked in the case
> where other programs were losing because they were using the 2.2
> kernel ABI, but the libc was using the 2.4 kernel ABI. Sigh.)
>
> So obviously, the way I need to fix e2fsprogs is to fork a child
> process, check to see whether or not I can safely call setrlimit, and
> if not, exit without trying to set it. :-( This is a really dirty
> hack, but I don't see any other way fixing user-land programs that are
> trying to work around this ABI mess.

I don't think you can tell whether it's safe to call setrlimit (unless you
mean having e2fsck call the *syscall* directly, which is icky). The
getrlimit in a 2.2-headered glibc returns 0x7FFFFFFF whether the kernel's
idea of the value is 0x7FFFFFFF or 0xFFFFFFFF. I still like Andreas Dilger's
idea that you only set the limit if it's not already RLIM_INFINITY as
returned by glibc.

If PAM, or something else, has already set the 0x7FFFFFFF value, there
appears to be no way of setting the 0xFFFFFFFF value via a 2.2-headered
glibc :-( and you'd need to go for the syscall :-((

Peter