[Xen-bugs] [Bug 90] Oops on vif teardown

[bugzilla-daemon@xxxxxxxxxxxxxxxxxxx]

http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=90





------- Additional Comments From ryanh@xxxxxxxxxx  2005-08-18 20:44 -------
Created an attachment (id=43)
 --> (http://bugzilla.xensource.com/bugzilla/attachment.cgi?id=43&action=view)
Workaround for double call to br_del_if()

There appears to be a race between when the first br_del_if() call sets port
state to disabled, and then when the dev->br_port pointer is set to NULL. 
Every so often when unregister_netdevice() triggers the notify call change,
br_device_event() routine gets NETDEV_UNREGISTER event, but device->br_port
isn't NULL yet.  br_port is set to NULL after br_del_if() call del_npb() which
calls 
destroy_npb().  

So, good sequence:

br_del_if()
  del_nbp()
     // port state set to disabled, but dev->br_port is not NULL
     br_stp_disable_port()
     destroy_nbp_rcu()
        // set dev->br_port = NULL, among other things
        destroy_nbp()

notify_call_chain()
  br_device_event()
     dev->br_port == NULL, bail.

-----------------------------------------
bad sequence:

br_del_if()
  del_nbp()
     // port state set to disabled, but dev->br_port is not NULL
     br_stp_disable_port()
// notify call chain gets scheduled 
notify_call_chain()
  br_device_event()
     dev->br_port != NULL
     br_del_if()
       BOOM!


-- 
Configure bugmail: 
http://bugzilla.xensource.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

_______________________________________________
Xen-bugs mailing list
Xen-bugs@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-bugs