From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752295AbcFNOuc (ORCPT ); Tue, 14 Jun 2016 10:50:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59807 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751635AbcFNOu2 (ORCPT ); Tue, 14 Jun 2016 10:50:28 -0400 Date: Tue, 14 Jun 2016 16:50:20 +0200 From: Oleg Nesterov To: Topi Miettinen Cc: linux-kernel@vger.kernel.org, Andrew Morton , Ingo Molnar , "Amanieu d'Antras" , Stas Sergeev , Dave Hansen , Wang Xiaoqiang , Helge Deller , Sasha Levin Subject: Re: [RFC 14/18] limits: track RLIMIT_SIGPENDING actual max Message-ID: <20160614145019.GA32429@redhat.com> References: <1465847065-3577-1-git-send-email-toiwoton@gmail.com> <1465847065-3577-15-git-send-email-toiwoton@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1465847065-3577-15-git-send-email-toiwoton@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 14 Jun 2016 14:50:28 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/13, Topi Miettinen wrote: > > Track maximum number of pending signals, presented in /proc/self/limits. > > Signed-off-by: Topi Miettinen > --- > 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.