[lkml]   [2011]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 2/4] posix-timers: limit the number of posix timers per process
    On Tue, 30 Aug 2011 15:06:30 -0700
    Andi Kleen <> wrote:

    > > Sorry, it should be an rlimit from day one, IMO.
    > >
    > Ok.
    > > Partly because rlimits are a better implementation.
    > The reason I went with a sysctl is that rlimits are more intrusive for
    > user space,
    > requires special tools or patching bash.

    Yes, deployment for new rlimits is a big PITA. It would be sensible to
    modify the shells to take some anonymous numeric argument, so you could

    ulimit 42 1000

    to set rlimit number 42 if your shell version doesn't understand the
    symbolic representation of more recent additions. Who do I call?

    There was code floating about which would permit rlimits to be modified
    from other processes, perhaps by making /proc/pid/limits writable. I
    don't think it got merged. I have a vague feeling that this might be
    my fault.

    > > Partly because once rlimits are added, the /proc knob no longer has any
    > > sane behaviour. Does it only modify /sbin/init? Does it do a global
    > > process walk, modifying all threads?
    > There's no way to modify: you would need to kill the process or randomly
    > take timers away. The limit only applies to new timers.

    Sure, it applies to new timers. My concern is: what does a write to
    the old /proc knob _do_? Modify all the system's task_struct.rlim[],
    overwriting whatever was there? Something else? It would need to at
    least roughly emulate the old behaviour.

     \ /
      Last update: 2011-08-31 00:31    [W:0.032 / U:15.324 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site