Messages in this thread | | | Date | Tue, 16 Jun 2015 09:54:14 +0200 | From | Petr Mladek <> | Subject | Re: [RFC PATCH 06/18] signal/kthread: Initial implementation of kthread signal handling |
| |
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(¤t->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
| |