Messages in this thread | | | Date | Thu, 01 Apr 2010 13:14:38 +0900 | From | Tejun Heo <> | Subject | Re: [Patch] workqueue: move lockdep annotations up to destroy_workqueue() |
| |
Hello,
On 04/01/2010 01:09 PM, Cong Wang wrote: >> This seems to be from the original thread of frame#3. It's grabbing >> wq lock here but the problem is that the lock will be released >> immediately, so bond_dev->name (the wq) can't be held by the time it >> reaches frame#3. How is this dependency chain completed? Is it >> somehow transitive through rtnl_mutex? > > wq lock is held *after* cpu_add_remove_lock, lockdep also said this, > the process is trying to hold wq lock while having cpu_add_remove_lock.
Yeah yeah, I'm just failing to see how the other direction is completed. ie. where does the kernel try to grab cpu_add_remove_lock *after* grabbing wq lock?
>> Isn't there a circular dependency here? bonding_exit() calls >> destroy_workqueue() under rtnl_mutex but destroy_workqueue() should >> flush works which could be trying to grab rtnl_lock. Or am I >> completely misunderstanding locking here? > > Sure, that is why I sent another patch for bonding. :)
Ah... great. :-)
> After this patch, another lockdep warning appears, it is exactly what > you expect.
Hmmm... can you please try to see whether this circular locking warning involving wq->lockdep_map is reproducible w/ the bonding locking fixed? I still can't see where wq -> cpu_add_remove_lock dependency is created.
Thanks.
-- tejun
| |