On Thu, 26 Jan 2006 19:45:06 +1100
Herbert Xu <[EMAIL PROTECTED]> wrote:
> 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.
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
...
> 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,
--
Stephen Hemminger <[EMAIL PROTECTED]>
OSDL http://developer.osdl.org/~shemminger
-
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
