Re: [RFC PATCH 06/18] signal/kthread: Initial implementation of kthread signal handling

[Petr Mladek]

On Mon 2015-06-15 21:14:29, Oleg Nesterov wrote:
> Ah, understand. You think that we need to take ->siglock in advance
> to avoid the race with SIGCONT?

exactly

> No, we don't. Let me show you the code I suggested again:
> 
>       void kthread_do_signal_stop(void)
>       {
>               spin_lock_irq(&curtent->sighand->siglock);
>               if (current->jobctl & JOBCTL_STOP_DEQUEUED)
>                       __set_current_state(TASK_STOPPED);
>               spin_unlock_irq(&current->sighand->siglock);
> 
>               schedule();
>       }
>       
> so you can dequeue_signal() and call kthread_do_signal_stop() without
> holding ->siglock. We can rely on JOBCTL_STOP_DEQUEUED bit. SIGCONT
> clears it, so kthread_do_signal_stop() can't race.

Heureka, I have got it. I have previously missed the meaning of the
JOBCTL_STOP_DEQUEUED bit. Thanks for explanation.

Best Regards,
Petr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/