On Mon, Jan 30, 2006 at 03:44:15PM -0800, Stephen Hemminger wrote:
> Or could use STP state, but the extra pointers aren't that much
> anyway.
Well it'll make the patch smaller and easier to read at least :)
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTEC
On Tue, 31 Jan 2006 10:11:10 +1100
Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 26, 2006 at 03:05:54PM -0800, Stephen Hemminger wrote:
> > Plan B:
> > 1. Use p->br (the back pointer) as the RCU sentinel
>
> A thought just came to mind. What about adding a dead flag (p->dead)?
> That means
On Thu, Jan 26, 2006 at 03:05:54PM -0800, Stephen Hemminger wrote:
> Plan B:
> 1. Use p->br (the back pointer) as the RCU sentinel
A thought just came to mind. What about adding a dead flag (p->dead)?
That means you won't have to carry around all those extra pointers.
So on the deleting path, yo
On Thu, Jan 26, 2006 at 03:05:54PM -0800, Stephen Hemminger wrote:
> Plan B:
> 1. Use p->br (the back pointer) as the RCU sentinel
> 2. Keep dev->br_port set until after the RCU transition
> 3. Order operations so we don't have to worry about p->br being NULL
>in the case of STP timers.
This s
On Thu, Jan 26, 2006 at 03:01:00PM -0800, Stephen Hemminger wrote:
>
> Well, it was before I changed del_nbp to set dev->br_port to NULL.
> So what br_del_if would get called twice for same port.
Right. I wasn't questioning the zeroing of dev->br_port. I was
just saying that placing a barrier u
Plan B:
1. Use p->br (the back pointer) as the RCU sentinel
2. Keep dev->br_port set until after the RCU transition
3. Order operations so we don't have to worry about p->br being NULL
in the case of STP timers.
Untested. Probably excessive use of rcu() macros. Since it is only
needed in cases
On Fri, 27 Jan 2006 09:29:12 +1100
Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 27, 2006 at 07:33:24AM +1100, herbert wrote:
> >
> > > 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_de
On Fri, Jan 27, 2006 at 07:33:24AM +1100, herbert wrote:
>
> > 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 ev
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;
> > >
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_i
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
Use RCU macro's to ensure barrier safety on the bridge
receive path.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- 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;
s
12 matches
Mail list logo
