Messages in this thread | | | From | "Peter Hartley" <> | Subject | Re: setrlimit and RLIM_INFINITY causing fsck failure, 2.4.18 | Date | Wed, 20 Mar 2002 10:09:10 -0000 |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |