[lkml]   [2002]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: setrlimit and RLIM_INFINITY causing fsck failure, 2.4.18
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 :-((


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:22    [W:0.095 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site