lkml.org 
[lkml]   [2010]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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.



    \
     
     \ /
      Last update: 2010-06-19 00:41    [W:4.412 / U:0.728 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site