This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH] patches: workaround for br_del_if race

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] patches: workaround for br_del_if race
From: Ryan Harper <ryanh@xxxxxxxxxx>
Date: Fri, 19 Aug 2005 11:46:29 -0500
Cc: Kip Macy <kip.macy@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 19 Aug 2005 16:45:15 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <444f954bea7fae40ba1d737b7f488bb2@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20050818210134.GG10593@xxxxxxxxxx> <444f954bea7fae40ba1d737b7f488bb2@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.6+20040907i
* Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> [2005-08-19 07:37]:
> On 18 Aug 2005, at 22:01, Ryan Harper wrote:
> >This patch provides a workaround for bugzilla #90 which shows up far 
> >too
> >often when creating and then destroying lots of domUs and dom0 is SMP.
> >Details are in the [1]bug.  With this patch, I now can create/destroy
> >domains in a tight loop for hours where previously every 3 to 10 cycles
> >would blow up.
> Please also submit this to the Ethernet bridge maintainer. Details are 
> in the Linux MAINTAINERS file.

I've had a little discussion on [1]netdev about this but since this
isn't the proper fix I'm doing some more digging.

The real race is between when a call_rcu() callback runs and when the
netif_destroy() calls unregister_netdev().  

When we get an oops, the brctl delif IOCTL has run, and br_del_if() has
been called setting the port state to DISABLED, and then queues up an
rcu callback, destroy_npb(),  which will set dev->br_port = NULL.  

add_del_if()                       // IOCTL handler from brctl delif 
                                   // xen-br0 $VIF
      br_stp_disable_port()        // Set port->state = BR_STATE_DISABLED
      call_rcu(destroy_nbp_rcu)    // setup rcu callback to run 
                                   // destory_nbp() which will set
                                   // dev->br_port = NULL
After the xen scripts have called the brctl command, xend sends the
disconnect and destroy control messages, which trigger:

            br_device_event()    // The first thing done here is to check 
                                 // the device's br_port to see if it is
                                 // NULL

If the destory_nbp_rcu() callback isn't fired before br_device_event()
checks dev->br_port, then the NULL check fails and a second call to
br_del_if() is invoked and we blow up in sysfs/kobject BUG_ON() for ref
counts of dentrys. [2]

Before I go back to netdev, I wanted to check if there is anything we
should be doing to be more defensive or does this seem to be something
the bridge code should handle (error out, whatever)?

1. http://oss.sgi.com/archives/netdev/2005-08/msg00097.html
2. Routines are in linux/net/bridge/{br_if.c, br_ioctl.c, br_notify.c}

Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253

Xen-devel mailing list