lkml.org 
[lkml]   [2018]   [Jul]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 18/20] signal: Add calculate_sigpending()
On 07/23, Eric W. Biederman wrote:
>
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -1988,6 +1988,7 @@ static __latent_entropy struct task_struct *copy_process(
> &p->signal->thread_head);
> }
> attach_pid(p, PIDTYPE_PID);
> + calculate_sigpending(p);

In theory this looks racy if !CLONE_SIGHAND, please see below

> +void calculate_sigpending(struct task_struct *new)
> +{
> + /* Have any signals or users of TIF_SIGPENDING been delayed
> + * until after fork?
> + */
> + bool pending = (new->jobctl & JOBCTL_PENDING_MASK) ||
> + PENDING(&new->pending, &new->blocked) ||
> + PENDING(&new->signal->shared_pending, &new->blocked) ||
> + freezing(new) || klp_patch_pending(new);

note that we do not hold new->sighand->siglock, but this "new" task is already
visible to find_task_by_vpid/etc; so a new signal can come right after this check,

> + update_tsk_thread_flag(new, TIF_SIGPENDING, pending);

and then update_tsk_thread_flag() can wrongly clear TIF_SIGPENDING.

Easy to fix, but perhaps we can simply add recalc_sigpending() into
schedule_tail() ? It already does more than just finish_task_switch/etc.

This way we do not need the new helper (which btw can only be used by
copy_process).


Note also that either way you can remove set_tsk_thread_flag(TIF_SIGPENDING)
from ptrace_init_task().

Oleg.

\
 
 \ /
  Last update: 2018-07-26 15:21    [W:0.213 / U:3.604 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site