Messages in this thread | | | Date | Sat, 19 Jun 2010 00:37:13 +0200 | From | Oleg Nesterov <> | Subject | Re: while_each_thread() under rcu_read_lock() is broken? |
| |
On 06/18, Roland McGrath wrote: > > I think you're right. I can't see what would prevent that race.
How sad.
> So for_each_process
for_each_process() looks fine. It uses init_task as the anchor, it can't go away, it is swapper.
> and do_each_thread are safe only under > read_lock(&tasklist_lock) and while_each_thread is only safe under > either that or siglock.
Yes,
(Also a few places using next_thread in > similar loops outside those macros.)
I hope that most (all?) of next_thread() users can be converted to use while_each_thread().
> Perhaps we could move those del's from __unhash_process to > __put_task_struct (or just delayed_put_task_struct?)
This needs write_lock_irq(tasklist), we can't take it in atomic context. And I bet this change (at least right now) has other implications.
> I think de_thread() in exec-by-nonleader is the only case where this > can happen, right? So then perhaps we could make it call release_task > only via call_rcu?
Hmm, perhaps... I am already sleeping, will try to check this idea tomorrow. At first glance, it looks promising to me. And I see the email from Paul which is too late to read for me today ;)
In any case, I _think_ we can fix while_each_thread(), say XXX(t) from the previous email. But then we should audit the users like zap_threads() which assume we should not miss any "interesting" task. Probably zap_threads() is fine because of mmap_sem, but I can't think properly now.
Oleg.
| |