[lkml]   [2009]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Patch in this message
    Subject[patch 05/53] revert "rlimit: permit setting RLIMIT_NOFILE to RLIM_INFINITY"
    2.6.28-stable review patch.  If anyone has any objections, please let us know.

    From: Andrew Morton <>

    commit 60fd760fb9ff7034360bab7137c917c0330628c2 upstream.

    Revert commit 0c2d64fb6cae9aae480f6a46cfe79f8d7d48b59f because it causes
    (arguably poorly designed) existing userspace to spend interminable
    periods closing billions of not-open file descriptors.

    We could bring this back, with some sort of opt-in tunable in /proc, which
    defaults to "off".

    Peter's alanysis follows:

    : I spent several hours trying to get to the bottom of a serious
    : performance issue that appeared on one of our servers after upgrading to
    : 2.6.28. In the end it's what could be considered a userspace bug that
    : was triggered by a change in 2.6.28. Since this might also affect other
    : people I figured I'd at least document what I found here, and maybe we
    : can even do something about it:
    : So, I upgraded some of's machines to and immediately
    : the team maintaining our ftp archive complained that one of their
    : scripts that previously ran in a few minutes still hadn't even come
    : close to being done after an hour or so. Downgrading to 2.6.27 fixed
    : that.
    : Turns out that script is forking a lot and something in it or python or
    : whereever closes all the file descriptors it doesn't want to pass on.
    : That is, it starts at zero and goes up to ulimit -n/RLIMIT_NOFILE and
    : closes them all with a few exceptions.
    : Turns out that takes a long time when your limit -n is now 2^20 (1048576).
    : With 2.6.27.* the ulimit -n was the standard 1024, but with 2.6.28 it is
    : now a thousand times that.
    : 2.6.28 included a patch titled "rlimit: permit setting RLIMIT_NOFILE to
    : RLIM_INFINITY" (0c2d64fb6cae9aae480f6a46cfe79f8d7d48b59f)[1] that
    : allows, as the title implies, to set the limit for number of files to
    : infinity.
    : Closer investigation showed that the broken default ulimit did not apply
    : to "system" processes (like stuff started from init). In the end I
    : could establish that all processes that passed through pam_limit at one
    : point had the bad resource limit.
    : Apparently the pam library in Debian etch (4.0) initializes the limits
    : to some default values when it doesn't have any settings in limit.conf
    : to override them. Turns out that for nofiles this is RLIM_INFINITY.
    : Commenting out "case RLIMIT_NOFILE" in pam_limit.c:267 of our pam
    : package version 0.79-5 fixes that - tho I'm not sure what side effects
    : that has.
    : Debian lenny (the upcoming 5.0 version) doesn't have this issue as it
    : uses a different pam (version).

    Reported-by: Peter Palfrader <>
    Cc: Adam Tkac <>
    Cc: Michael Kerrisk <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>

    kernel/sys.c | 16 ++++------------
    1 file changed, 4 insertions(+), 12 deletions(-)

    --- a/kernel/sys.c
    +++ b/kernel/sys.c
    @@ -1447,22 +1447,14 @@ SYSCALL_DEFINE2(setrlimit, unsigned int,
    return -EINVAL;
    if (copy_from_user(&new_rlim, rlim, sizeof(*rlim)))
    return -EFAULT;
    + if (new_rlim.rlim_cur > new_rlim.rlim_max)
    + return -EINVAL;
    old_rlim = current->signal->rlim + resource;
    if ((new_rlim.rlim_max > old_rlim->rlim_max) &&
    return -EPERM;
    - if (resource == RLIMIT_NOFILE) {
    - if (new_rlim.rlim_max == RLIM_INFINITY)
    - new_rlim.rlim_max = sysctl_nr_open;
    - if (new_rlim.rlim_cur == RLIM_INFINITY)
    - new_rlim.rlim_cur = sysctl_nr_open;
    - if (new_rlim.rlim_max > sysctl_nr_open)
    - return -EPERM;
    - }
    - if (new_rlim.rlim_cur > new_rlim.rlim_max)
    - return -EINVAL;
    + if (resource == RLIMIT_NOFILE && new_rlim.rlim_max > sysctl_nr_open)
    + return -EPERM;

    retval = security_task_setrlimit(resource, &new_rlim);
    if (retval)

     \ /
      Last update: 2009-02-10 20:09    [W:0.026 / U:5.312 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site