Date:	Mon, 28 Jul 2008 20:51:12 +0530
From:	"Narendra Prasad Madanapalli" <narendramind@...il.com>
To:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: akpm@...l.org,mtk.manpages@...il.com

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@...il.com>

Download attachment "patch-2.6.26-rlim64" of type "application/octet-stream" (10744 bytes)

Powered by blists - more mailing lists