Problem Description:
The following issue affects the setrlimit() and getrlimit() system
calls on Linux 2.6.13 (and earlier) on x86.
The Problem is filed at kernel.org bug 5042
(http://bugzilla.kernel.org/show_bug.cgi?id=5042)
With setrlimit()/getrlimit(), resource limits can not be set >
2^32-1 on x86 as internally, resource limits are represented in the
'rlimit' structure (defined in include/linux/resource.h) as unsigned
longs, meaning 32 bits on x86. 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.
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.)
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.
Design Approach:
Add two system calls sys_setrlimit64()/sys_getrlimit64().
And a type 'struct rlimit64' to accomodate limits more <= 2^64-1
Implementation Details:
Inclutions: struct rlimit64, struct rlimit64
rlim64[RLIM64_NRLIMITS] to task_struct
Test Results:
Test results are posted as Comment#6 to
http://bugzilla.kernel.org/show_bug.cgi?id=5042
Issues Facing:
Though the limits of 'rlim64 of task_struct' are initialized
to RLIM64_INFINITY in linux/init_task.h, garbage values are set to
them. Placed some printks in sys_getrlimit64 to print the values of
'rlim64 of task_struct'; the printk statements will be execute when
getrlimit64() is invoked.
the output of dmesg is as follows:
[ 111.221402] resource = 1, RLIM64_INFINITY = ffffffffffffffff,
RLIMIT_FSIZE = 1, RLIM64_NLIMITS = 2
[ 111.221411] current rlim64 : max64 = f4967194, cur64 =
f496719400000001
[ 111.221416] value (local var, before) : max64 = c02f9730b7f4cce0,
cur64 =b7f18ff4f4ae5e00
[ 111.221421] value (after assignment) : max64 = f4967194, cur64 =
f496719400000001
[ 118.437395] resource = 1, RLIM64_INFINITY = ffffffffffffffff,
RLIMIT_FSIZE = 1, RLIM64_NLIMITS = 2
[ 118.437406] current rlim64 : max64 = f499ff98f499ff98,
cur64 = fe86a13df498a628
[ 118.437411] value (local var, before) : max64 = c02f9730b7f94ce0,
cur64 = b7f60ff4f4b41e00
[ 118.437419] value (after assignment) : max64 = f499ff98f499ff98,
cur64 = fe86a13df498a628
Signed-off-by: Narendra Prasad Madanapalli <narendramind@xxxxxxxxx>
Attachment:
patch-2.6.26-rlim64
Description: Binary data
