On 06/13, Topi Miettinen wrote: > > Track maximum number of pending signals, presented in /proc/self/limits. > > Signed-off-by: Topi Miettinen <toiwo...@gmail.com> > --- > kernel/signal.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/kernel/signal.c b/kernel/signal.c > index 96e9bc4..c8fbccd 100644 > --- a/kernel/signal.c > +++ b/kernel/signal.c > @@ -387,6 +387,8 @@ __sigqueue_alloc(int sig, struct task_struct *t, gfp_t > flags, int override_rlimi > INIT_LIST_HEAD(&q->list); > q->flags = 0; > q->user = user; > + /* XXX resource limits apply per task, not per user */ > + bump_rlimit(RLIMIT_SIGPENDING, atomic_read(&user->sigpending));
Well, I have to admit that I too dislike the very idea of these changes... But this particular patch looks wrong in any case. I wasn't cc'ed on the previous patches which add bump_rlimit(), but I have found "[RFC 05/18] limits: track and present RLIMIT_NOFILE actual max" http://marc.info/?l=linux-fsdevel&m=146584742331072&w=2 and bump_rlimit() changes current->signal->rlim_curmax, while in this case you need to bump t->signal->rlim_curmax. Oleg.