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:0.130 / U:4.716 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site