[PATCH] copy_process: remove the unneeded clear_tsk_thread_flag(TIF_SIGPENDING)

[PATCH] copy_process: remove the unneeded clear_tsk_thread_flag(TIF_SIGPENDING)

[Oleg Nesterov]

The forked child can have TIF_SIGPENDING if it was copied from parent's
ti->flags. But this is harmless and actually almost never happens, because
copy_process() can't succeed if signal_pending() == T.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>

--- PTRACE/kernel/fork.c~FORK_SIGPENDING	2009-04-13 17:05:52.000000000 +0200
+++ PTRACE/kernel/fork.c	2009-04-27 21:38:57.000000000 +0200
@@ -1027,7 +1027,6 @@ static struct task_struct *copy_process(
 	p->vfork_done = NULL;
 	spin_lock_init(&p->alloc_lock);
 
-	clear_tsk_thread_flag(p, TIF_SIGPENDING);
 	init_sigpending(&p->pending);
 
 	p->utime = cputime_zero;

Re: [PATCH] copy_process: remove the unneeded clear_tsk_thread_flag(TIF_SIGPENDING)

[Roland McGrath]

Acked-by: Roland McGrath <roland@redhat.com>

> The forked child can have TIF_SIGPENDING if it was copied from parent's
> ti->flags. But this is harmless and actually almost never happens, because
> copy_process() can't succeed if signal_pending() == T.

When it does happen, it's actually improper to clear it.  In a CLONE_THREAD
case, the pending signals might include shared_pending signals that the
child too should take.  (Arguably there is no way to notice, since the
parent thread will be racing to dequeue the same signals.)


Thanks,
Roland

Re: [PATCH] copy_process: remove the unneeded clear_tsk_thread_flag(TIF_SIGPENDING)

[Oleg Nesterov]

On 04/27, Roland McGrath wrote:
>
> Acked-by: Roland McGrath <roland@redhat.com>
>
> > The forked child can have TIF_SIGPENDING if it was copied from parent's
> > ti->flags. But this is harmless and actually almost never happens, because
> > copy_process() can't succeed if signal_pending() == T.
>
> When it does happen, it's actually improper to clear it.  In a CLONE_THREAD
> case, the pending signals might include shared_pending signals that the
> child too should take.  (Arguably there is no way to notice, since the
> parent thread will be racing to dequeue the same signals.)

Yes, sure. Now I see the changelog is not very clear.

I meant, it is possible that the parent has the false TIF_SIGPENDING which
is cleared later by recalc_sigpending(). In this case it is correct to do
clear_tsk_thread_flag(p, TIF_SIGPENDING), but this almost never happens.

Oleg.