| Summary: | setrlimit broken on old i386 kernels | ||
|---|---|---|---|
| Product: | uClibc | Reporter: | Michael Deutschmann <michael> |
| Component: | Other | Assignee: | unassigned |
| Status: | NEW --- | ||
| Severity: | minor | CC: | uclibc-cvs |
| Priority: | P5 | ||
| Version: | 0.9.30.3 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Host: | i386-pc-linux-uclibc | Target: | |
| Build: | |||
| Attachments: |
Fix for setrlimit on old kernels
Fix for setrlimit on old kernels, against 0.9.31 Fix for setrlimit on old kernels, against 0.9.32 |
||
Created attachment 1747 [details]
Fix for setrlimit on old kernels, against 0.9.31
Here is a version of the patch for the current release version, 0.9.31
(In reply to comment #1) > Created attachment 1747 [details] > Fix for setrlimit on old kernels, against 0.9.31 > > Here is a version of the patch for the current release version, 0.9.31 Can you handle that in libc/sysdeps/linux/common/bits/kernel-features.h instead? TIA, Created attachment 3421 [details]
Fix for setrlimit on old kernels, against 0.9.32
|
Created attachment 1435 [details] Fix for setrlimit on old kernels On Linux 2.0.40, setting a limit to infinity with setrlimit() produces an error. The problem is that __UCLIBC_HANDLE_OLDER_RLIMIT__ is incorrectly switched off for the i386 platform. Reversing that fixes the bug. However, this bug seems to exist to paper over a separate bug, which would otherwise cause 2.4+ kernels to be treated like 2.2/2.0. This is that the code assumes that all kernels with a history of signed int limits but current support for unsigned int limits, provide a "usetrlimit" system call. But recent kernels actually add only a ugetrlimit call. I'm attaching a patch that fixes the define, and also fixes the code so that *either* the absence of __UCLIBC_HANDLE_OLDER_RLIMIT__, or the presence of __NR_ugetrlimit, is enough to allow > 2^31 limits to be passed to the setrlimit syscall. This should avoid any regression on 2.4/2.6.