Messages in this thread |  | | | Date | Sun, 23 Nov 2008 22:55:11 +0100 | | From | Oleg Nesterov <> | | Subject | do_wait() vs do_notify_parent_cldstop() theoretical race? |
| |
Looking at do_wait(), suddenly I am starting to suspect we have the highly theoretical race with do_notify_parent_cldstop().
do_wait:
add_wait_queue(...);
current->state = TASK_INTERRUPTIBLE;
read_lock(tasklist_lock);
... try to find the "interesting" task ...
read_unlock(tasklist_lock);
if (!retval) // not found schedule(); We don't race with do_notify_parent() because it takes tasklist for writing. But do_notify_parent_cldstop() can run in parallel under read_lock(tasklist).
Now suppose that "->state = TASK_INTERRUPTIBLE" leaks deeply into the critical section. In theory, it is possible that wait_consider_task() checks task_is_stopped_or_traced() or SIGNAL_STOP_CONTINUED first, then CPU sets state = TASK_INTERRUPTIBLE. And we can miss the event if do_notify_parent_cldstop() happens in between.
No?
Oleg.
|  |