lkml.org 
[lkml]   [2008]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 2.6.27-rc5] Allow set RLIMIT_NOFILE to RLIM_INFINITY
    On Wed, Sep 10, 2008 at 02:31:41PM -0700, Andrew Morton wrote:
    > On Tue, 9 Sep 2008 09:14:07 +0200
    > Adam Tkac <vonsch@gmail.com> wrote:
    >
    > > when process wants set limit of open files to RLIM_INFINITY it gets
    > > EPERM even if it has CAP_SYS_RESOURCE capability. Attached patch
    > > should fix the problem. Please add me to CC of your responses because
    > > I'm not member of list.
    > >
    > > Regards, Adam
    > >
    > > --
    > > Adam Tkac
    > >
    > >
    > > [linux26-openfiles.patch text/plain (634B)]
    > > --- a/kernel/sys.c
    > > +++ b/kernel/sys.c
    > > @@ -1458,8 +1458,14 @@ asmlinkage long sys_setrlimit(unsigned i
    > > if ((new_rlim.rlim_max > old_rlim->rlim_max) &&
    > > !capable(CAP_SYS_RESOURCE))
    > > return -EPERM;
    > > - if (resource == RLIMIT_NOFILE && new_rlim.rlim_max > sysctl_nr_open)
    > > - 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;
    > > + }
    >
    > The kernel has had this behaviour for a long time. 2.6.13 had:
    >
    > if ((new_rlim.rlim_max > old_rlim->rlim_max) &&
    > !capable(CAP_SYS_RESOURCE))
    > return -EPERM;
    > if (resource == RLIMIT_NOFILE && new_rlim.rlim_max > NR_OPEN)
    > return -EPERM;
    >
    > I don't immediately see a problem with your change, but what makes you
    > believe that it is needed? Is there some standard which we're
    > violating? Is there some operational situation in which the current
    > behaviour is causing a problem?
    >
    > Thanks.

    Well, this change is not _absolutely_ needed because everyone who wants
    unlimited file descriptors he could set it to NR_OPEN. Look on
    example (from BIND):

    ...
    #elif defined(NR_OPEN) && defined(__linux__)
    /*
    * Some Linux kernels don't accept RLIM_INFINIT; the maximum
    * possible value is the NR_OPEN defined in linux/fs.h.
    */
    if (resource == isc_resource_openfiles && rlim_value == RLIM_INFINITY) {
    rl.rlim_cur = rl.rlim_max = NR_OPEN;
    unixresult = setrlimit(unixresource, &rl);
    if (unixresult == 0)
    return (ISC_R_SUCCESS);
    }
    #elif ...

    I think that when you allow set RLIMIT_NOFILE to RLIM_INFINITY you
    increase portability - you don't have to check if OS is linux and then
    use different schema for limits.

    Regards, Adam

    --
    Adam Tkac


    \
     
     \ /
      Last update: 2008-09-11 09:57    [W:0.023 / U:2.116 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site