On Thu, Jan 26, 2006 at 09:41:00AM -0800, Stephen Hemminger wrote: > > > > --- br-fix.orig/net/bridge/br_if.c > > > +++ br-fix/net/bridge/br_if.c > > > @@ -124,7 +124,7 @@ static void del_nbp(struct net_bridge_po > > > struct net_bridge *br = p->br; > > > struct net_device *dev = p->dev; > > > > > > - dev->br_port = NULL; > > > + rcu_assign_pointer(dev->br_port, NULL); > > > > I think this barrier is in the wrong place. On the deletion path what > > we want to achieve is separate the zeroing of dev->br_port and the > > actual freeing of the br_port object through a quiescent state. This > > is already achieved by the RCU call further down. > > That breaks because of the race (found by Xen) where an interface > is being deleted from a bridge and the device is being removed. > > br_del_if > rmmod device > netlink event > br_device_event > ...
Sorry, I don't get it. How does adding a barrier in del_nbp fix this bug? In fact, as far as I can see, you need to add a pair of rcu_read_lock/rcu_read_unlock in br_device_event to make it work. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
