Re: [PATCH] set RLIMIT_SIGPENDING limit based on RLIMIT_NPROC

[Chris Wright <chrisw@osdl.org>]

* Roland McGrath (roland@redhat.com) wrote:
> While looking into the issues Jeremy had with the RLIMIT_SIGPENDING limit,
> it occurred to me that the normal setting of this limit is bizarrely low.
> The initial hard limit setting (MAX_SIGPENDING) was taken from the old
> max_queued_signals parameter, which was for the entire system in aggregate.
> But even as a per-user limit, the 1024 value is incongruously low for this.

But the old default system-wide limit was 1024.  And you could have
spawned 8k processes then as well.  So I don't think this matters much.

> On my machine, RLIMIT_NPROC allows me 8192 processes, but only 1024 queued
> signals, i.e. fewer even than one pending signal in each process.  (To me,
> this really puts in doubt the sensibility of using a per-user limit for
> this rather than a per-process one, i.e. counted in sighand_struct or
> signal_struct, which could have a much smaller reasonable value.  I don't
> recall the rationale for making this new limit per-user in the first place.)

I don't either, the archives show using per-user as default choice
(never saw a discussion otherwise).  Users can easily queue signals to
themselves (using multiple processes or not), and there was some concern
that somebody actually wanted to be able queue up to 1024 (since it's
what was allowed in the past).

> This patch sets the default RLIMIT_SIGPENDING limit at boot time, using the
> calculation that decides the default RLIMIT_NPROC limit.  This uses the
> same value for those two limits, which I think is still pretty conservative
> on the RLIMIT_SIGPENDING value.

It's an rlimit, so easily setable in userspace at login session time.  I
think we could raise it if people start complaining it's too low (hasn't
seemed to be a problem yet).

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net