[lkml]   [2009]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0/3] extend get/setrlimit to support setting rlimits external to a process (v7)

    * Neil Horman <> wrote:

    > Ok, I give. I was hoping that some of the requestors of this feature
    > would pipe up and support the use case for the proc file interface to
    > set limits. clearly they're not that interested, but I still think
    > theres merit in the patch. So heres version 7 of this patch set. Its
    > the same as before, but the proc interface has been dropped, leaving
    > only the syscall interface behind. I've tested the interface on intel
    > 32 and 64 bit, with success
    > Summary:
    > Its been requested often that we have the ability to read and modify
    > process rlimit values from contexts external to the owning process.
    > Ideally this allows sysadmins to adjust rlimits on long running
    > processes wihout the need to stop and restart those processes, which
    > incurs undesireable downtime. This patch enables that functionality,
    > It does so in two places. First it enables process limit setting by
    > writing to the /proc/pid/limits file a string in the format: <limit>
    > <current limit> <max limit> > /proc/<pid>/limits where limit is one of
    > [as,core,cpu,data,fsize,locks,memlock,msgqueue,nice,nofile,nproc,rss,rtprio,rttime]
    > Secondly it allows for programatic setting of these limits via 2 new
    > syscalls, getprlimit, and setprlimit, which act in an identical
    > fashion to getrlimit and setrlimit respectively, except that they
    > except a process id as an extra argument, to specify the process id of
    > the rlimit values that you wish to read/write

    This looks potentially useful but i think the implementation might be
    too optimistic, from a security POV.

    Have you ensured that no rlimit gets propagated during task init into
    some other value - under the previously correct assumption that rlimits
    dont change asynchronously under the feet of tasks?

    Also, there's SMP safety: right now all the accesses to
    current->signal->rlim[] are unlocked and assume that if we are executing
    in a syscall those values cannot change. Is this a safe assumption on
    all SMP architectures?

    Plus, the locking looks structured in a weird way: why is the
    sighand-lock taken in the procfs code instead of moving it where the
    data structure is updated (the resource limits code).

    Also, a patch submission observation: every single patch you submitted
    here had a messed up title that had a 'Re: ' in it, making it hard to
    sort out what is the latest. Some of the patches also had their
    changelog indented. Please use the standard patch submission methods.

    So this patch-set needs more work.



     \ /
      Last update: 2009-11-02 16:29    [W:0.023 / U:14.072 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site