Messages in this thread | | | Subject | Re: [Patch] bonding: fix potential deadlock in bond_uninit() | From | (Eric W. Biederman) | Date | Wed, 31 Mar 2010 04:28:33 -0700 |
| |
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.
Is this a deadlock you actually hit, or is this something lockdep warned about?
My gut feel says we need to move the destroy_workqueue into the network device destructor.
Eric
> Signed-off-by: WANG Cong <amwang@redhat.com> > Cc: Jay Vosburgh <fubar@us.ibm.com> > Cc: "David S. Miller" <davem@davemloft.net> > Cc: Stephen Hemminger <shemminger@vyatta.com> > Cc: Jiri Pirko <jpirko@redhat.com> > Cc: "Eric W. Biederman" <ebiederm@xmission.com> > > --- > diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c > index 5b92fbf..b781728 100644 > --- a/drivers/net/bonding/bond_main.c > +++ b/drivers/net/bonding/bond_main.c > @@ -4542,8 +4542,11 @@ static void bond_uninit(struct net_device *bond_dev) > > bond_remove_proc_entry(bond); > > - if (bond->wq) > + if (bond->wq) { > + rtnl_unlock(); > destroy_workqueue(bond->wq); > + rtnl_lock(); > + } > > netif_addr_lock_bh(bond_dev); > bond_mc_list_destroy(bond);
| |