On 01/30/2017 02:31 PM, Boris Ostrovsky wrote: > On 01/30/2017 02:06 PM, Eric Dumazet wrote: >> On Mon, 2017-01-30 at 13:23 -0500, Boris Ostrovsky wrote: >> >>> We do netif_carrier_off() first thing in xennet_disconnect_backend() and >>> the only place where the timer is rearmed is xennet_alloc_rx_buffers(), >>> which is guarded by netif_carrier_ok() check. >> Oh well, testing netif_carrier_ok() in packet processing fast path looks >> unusual and a waste of cpu cycles. I've never seen that pattern before. >> >> If one day, we remove this netif_carrier_ok() test during a cleanup, >> then the race window will open again. > > I don't know much about napi but I wonder whether I can indeed disable > it in xennet_disconnect_backend(). I don't see how anything can happen > after disconnect since it unmaps the rings. And then napi is re-enabled > during reconnection in xennet_create_queues(). In which case am not sure > there is any need for xennet_destroy_queues() as everything there could > be folded into xennet_disconnect_backend(). While this does work, there was a reason why napi_disable() was not called in xennet_disconnect_backend() and it is explained in commit ce58725fec6e --- napi_disable() may sleep and that's why it is called in xennet_destroy_queues(). OTOH, there is a napi_synchronize() call in xennet_destroy_queues(). Will destroying the timer after it guarantee that all preceding RX have been completed? RX interrupt is disabled prior to napi_synchronize() so presumably nothing new can be received. -boris -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html