lkml.org 
[lkml]   [2009]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: workqueue thing

    * Linus Torvalds <torvalds@linux-foundation.org> wrote:

    > IOW, if you hold a lock, and then do 'flush_workqueue()', lockdep has no
    > idea that maybe one of the entries on a workqueue might need the lock that
    > you are holding. But I don't think lockdep sees the dependency that gets
    > created by the flush - because it's not a direct code execution dependency.

    Do you mean like the annotations we added in:

    4e6045f: workqueue: debug flushing deadlocks with lockdep
    a67da70: workqueues: lockdep annotations for flush_work()

    ?

    It looks like this currently in the worklet:

    lock_map_acquire(&cwq->wq->lockdep_map);
    lock_map_acquire(&lockdep_map);
    f(work);
    lock_map_release(&lockdep_map);
    lock_map_release(&cwq->wq->lockdep_map);

    and like this in flush:

    lock_map_acquire(&wq->lockdep_map);
    lock_map_release(&wq->lockdep_map);
    for_each_cpu(cpu, cpu_map)
    flush_cpu_workqueue(per_cpu_ptr(wq->cpu_wq, cpu));

    We basically track the implicit dependencies even if they are not executed
    (only theoretically possible) - and we subsequently caught a few bugs that
    way.

    Or did you have some other dependency in mind?

    Ingo


    \
     
     \ /
      Last update: 2009-12-18 16:43    [W:6.446 / U:0.848 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site