On Mon, Jan 23, 2006 at 12:05:26PM -0800, Stephen Hemminger wrote: > Use RCU macro's to ensure barrier safety on the bridge > receive path.
Thanks for working on this Stephen. > --- 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. On the other hand, when we set dev->br_port in the first instance, we do need the barrier. So we need to turn the br_port assignment in new_nbp into an rcu_assign_pointer. In fact, we also need to rearrange the code there so that we're 100% sure that the bridge port is fully initialised before we assign dev->br_port. This is because as soon as that assignment is made packets may start getting delivered to the bridge via this device. 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
