Revision 1 as of 2007-07-24 02:19:16
converted to 1.6 markup
|Deletions are marked like this.||Additions are marked like this.|
|Line 1:||Line 1:|
|The following problem description has been copied from [http://bugzilla.kernel.org/show_bug.cgi?id=5042 kernel.org bug 5042]. If you are implementing this feature, feel free to use this page however you want.||The following problem description has been copied from [[http://bugzilla.kernel.org/show_bug.cgi?id=5042|kernel.org bug 5042]]. If you are implementing this feature, feel free to use this page however you want.|
The following problem description has been copied from kernel.org bug 5042. If you are implementing this feature, feel free to use this page however you want.
The following issue affects the setrlimit() and getrlimit() system calls on Linux 2.6.13 (and earlier) on x86. (And probably it occurs on other 32-bit Linux platforms as well.)
Internally, resource limits are represented in the 'rlimit' structure (defined in include/linux/resource.h) as unsigned longs, meaning 32 bits on x86.
However, this data type is not wide enough. The most pertinent limit here is RLIMIT_FSIZE, which specifies the maximum size to which a file can grow: to be useful, this limit must be represented using a type that is as wide as the type used to represent file offsets, i.e., as wide as a 64-bit off_t.
Current versions of glibc (e.g., 2.3.5) deal with this situation somewhat strangely: if a program compiled with _FILE_OFFSET_BITS set to 64 (i.e., off_t is thus 'long long' -- 64 bits) tries to set a resource limit to a value larger than can be represented in a 32-bit unsigned long, then the glibc wrapper for setrlimit() silently converts the limit value to RLIM_INFINITY. (The rlimit_large.c program below can be used to demonstrate this behaviour.)
In other words, the requested resource limit setting is silently ignored. (One could argue that perhaps the glibc wrapper should give an error, rather than silently turning a very large limit into infinity; however, the glibc developers instead seem to have decided on the current behaviour as a means of dealing with what is fundamentally a kernel problem.)
(NOTE: This problem is not merely a theoretical one facing programmers developing new applications. Since many x86 distributions compile all (file) utilities with -D_FILE_OFFSET_BITS=64, this issue can bite end-users as well, if they expect to be able to set resource limits greater than 2^32-1.)
I guess that the solution to this problem would require new setrlimit64() and getrlimit64() system calls on x86, and the existing 32-bit system calls would need to be retained so that existing binaries would still run.