lkml.org 
[lkml]   [2016]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC 14/18] limits: track RLIMIT_SIGPENDING actual max
From
Date
On 06/14/16 14:50, Oleg Nesterov wrote:
> On 06/13, Topi Miettinen wrote:
>>
>> Track maximum number of pending signals, presented in /proc/self/limits.
>>
>> Signed-off-by: Topi Miettinen <toiwoton@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
>

I used git send-email --cc-cmd=scripts/get_maintainer.pl to generate the
CC lists. Is there a better way?

> and bump_rlimit() changes current->signal->rlim_curmax, while in this case
> you need to bump t->signal->rlim_curmax.
>
> Oleg.
>

Yes, I also added task_bump_rlimit() which would be better choice here.

-Topi

\
 
 \ /
  Last update: 2016-06-14 18:41    [W:1.518 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site