On 05/28, Oleg Nesterov wrote:
>
> On 05/27, tip-bot for Vegard Nossum wrote:
> >
> > Hide the false positive using the __GFP_NOTRACK_FALSE_POSITIVE flag.
> > Also made the rlimit override code a bit clearer by introducing a new
> > variable.
>
> I think the patch is fine , but I have a bit off-topic question.
>
> > --- a/kernel/signal.c
> > +++ b/kernel/signal.c
> > @@ -829,6 +829,7 @@ static int __send_signal(int sig, struct siginfo *info, struct task_struct *t,
> > {
> > struct sigpending *pending;
> > struct sigqueue *q;
> > + int override_rlimit;
> >
> > trace_sched_signal_send(sig, t);
> >
> > @@ -860,9 +861,13 @@ static int __send_signal(int sig, struct siginfo *info, struct task_struct *t,
> > make sure at least one signal gets delivered and don't
> > pass on the info struct. */
> >
> > - q = __sigqueue_alloc(t, GFP_ATOMIC, (sig < SIGRTMIN &&
> > - (is_si_special(info) ||
> > - info->si_code >= 0)));
> > + if (sig < SIGRTMIN)
> > + override_rlimit = (is_si_special(info) || info->si_code >= 0);
> > + else
> > + override_rlimit = 0;
>
> I never understood this "si_code >= 0" above. Afaics, the kernel never
> sends SI_USER signals. User-space can't use SI_USER too.
Oh. sys_kill() uses SI_USER.
It turns out I just don't understand what override_rlimit means.
Need to sleep.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|