Re: [PATCH 2/4] posix-timers: limit the number of posix timers perprocess

[Andrew Morton]

On Tue, 30 Aug 2011 15:06:30 -0700
Andi Kleen <ak@xxxxxxxxxxxxxxx> 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
do

	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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/