Messages in this thread | | | Date | Thu, 01 Apr 2010 10:49:05 +0800 | From | Cong Wang <> | Subject | Re: [Patch] bonding: fix potential deadlock in bond_uninit() |
| |
Eric W. Biederman wrote: > Amerigo Wang <amwang@redhat.com> writes: > >> bond_uninit() is invoked with rtnl_lock held, when it does destroy_workqueue() >> which will potentially flush all works in this workqueue, if we hold rtnl_lock >> again in the work function, it will deadlock. >> >> So unlock rtnl_lock before calling destroy_workqueue(). > > Ouch. That seems rather rude to our caller, and likely very > dangerous.
This is reasonable, because workqueue flush functions will potentially call all the work functions which could take the same lock taken before the flush call, thus deadlock.
> > Is this a deadlock you actually hit, or is this something lockdep > warned about?
It's only a lockdep warning.
> > My gut feel says we need to move the destroy_workqueue into > the network device destructor. >
Oh, this seems a better idea, as long as the destructor are not called with any locks holding.
Thanks!
| |