(add Roland)
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.
If we are going to cleanup this code, perhaps we should do
override_rlimit = (sig < SIGRTMIN) &&
(is_si_special(info) || SI_FROMKERNEL(info);
?
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
|