[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: netback commit history
>>> On 20.09.11 at 14:10, "Jan Beulich" <JBeulich@xxxxxxxx> wrote: >>>> On 20.09.11 at 13:26, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote: >> On Tue, 2011-09-20 at 12:04 +0100, Jan Beulich wrote: >>> One thing I wonder about in this context is whether the >>> netif_stop_queue() call from xenvif_close() shouldn't happen before >>> xenvif_down() (not the least for reasons of symmetry with >>> xenvif_open()). >> >> I seem to recall looking at that too, it was the same in the old kernels >> too and I didn't know why so I avoided touching it (I was doing too much >> other cleanup at the time to risk it). > > After looking further I don't think that would help (though I still think > it would be more correct), as netif_stop_queue() basically evaluates > to a set_bit() without any other locks taken. So it's completely > asynchronous wrt dev_hard_start_xmit() (and its callers, which are > the ones looking at the bit with HARD_TX_LOCK() carried out). Which in turn suggests that the upstream driver isn't safe either: There's nothing preventing vif->netbk from becoming NULL between the early check in xenvif_start_xmit() and its actual use in xen_netbk_queue_tx_skb(). I think vif->netbk needs to be latched into a local variable, checked against NULL, and passed instead of vif to xen_netbk_queue_tx_skb(). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |