lkml.org 
[lkml]   [2010]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: while_each_thread() under rcu_read_lock() is broken?
    Oleg Nesterov <oleg@redhat.com> writes:

    > On 06/21, Roland McGrath wrote:
    >>
    >> > Paul, Roland, do you see any problems from the correctness pov,
    >> > or a better fix for now?
    >> >
    >> > Perhaps it also makes sense to keep the old variant renamed to
    >> > while_each_thread_locked(), I dunno.
    >>
    >> Did we verify that only de_thread() can create the situation where a
    >> while_each_thread-style loop without either lock can be confused?
    >
    > I think yes, this is is the only case.
    >
    > I mean, while_each_thread(group_leader, t). If g != group_leader, then
    > the lockless while_each_thread() has problems with the plain exit(g).
    >
    > Afaics. The more I think about this, the more I feel confused ;)
    >
    > But if we start from ->group_leader, then while_each_thread() must
    > stop eventually. Otherwise we should assume that the dead (unhashed)
    > tasks can create the circular list, obviously this is not possible.
    >
    >> If
    >> that's so, then just changing it to avoid the situation seems like it
    >> would be less invasive overall.
    >
    > How? We should change ->group_leader uner write_lock_irq(tasklist),
    > synchronize_rcu() is not an option. We can't do call_rcu(release_task),
    > we can't take tasklist for writing in the softirq context. But even
    > if we could, this can't help in fact or I missed something.

    We already do: call_rcu(&p->rcu, delayed_put_task_struct); in release_task.
    We don't call release_task until after we have removed it as leader and
    dropped the write lock.

    At first glance it sounds like the group leader is safe as a stopping
    point for a rcu while_each_thread, and I expect the fact that
    de_thread takes everything down to a single thread, could have nice
    properties here. If pid_alive were only to fail on the group leader
    when de_thread is called I think we could legitimately say that an event
    we won't worry about. It is close enough to a new thread being created
    anyway.

    Eric


    \
     
     \ /
      Last update: 2010-06-21 23:23    [from the cache]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean