Re: [PATCH] xen-netfront: Delete rx_refill_timer in xennet_disconnect_backend()

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel