[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Re: [patch] netfront: unregister net device at backend_changed() if network_connect() failed



On 2008-11-18 12:49, Keir Fraser wrote:
> On 18/11/08 12:21, "Joe Jin" <joe.jin@xxxxxxxxxx> wrote:
> 
> >> If virtual devices are failing to initialise then a confusing no-mac
> >> interface is presumably the least of the user's worries?
> > 
> > However, initialized failed means device was unavailable, but
> > at system ifconfig -a also show it, might be user ask what is
> > it? why it disabled? is there anything wrong on my systgem :-)
> 
> And they'd be right wouldn't they: Yes, something *is* wrong! :-)
> 
> > So, I think if device failed to initialise we'd better unregister
> > it. how do you think?
> 
> Have you actually seen this problem occur, in stress tests or elsewhere? Or
> is this just a 'nice to have'? If the former I'd rather fix the bug!
> 

At vm config file set vif type to ioemu and booting guest with pv driver,
always saw the interface, unregister the device when network_connect(),
I just saw one nic with 8139 driver.


> One concern I have is that leaving an interface structure allocated but
> unregistered is not a state we've previously handled in netfront, and could
> cause bad kernel behaviour if, for example, the netif gets unprobed later.
> 

I think if device initilise failed, we'd better release all resources like
former's netif_free(): http://xen.markmail.org/message/2bp3xgsqzdofwoy6 
from patch description the patch tried to *"eliminates earlier workaround patch
for an observed crash."* 
In fact the crashed caused by not unregister the device made the interface's 
state is NETREG_REGISTERED, when network_connect() failed, call free_netdev()
would trigered BUG_ON, just add unregister_netdev() would solved the issue.


Thanks,
Joe




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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.