linux-kernel - Re: [PATCH] xen-netfront: Delete rx_refill_timer in xennet_disconnect

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 31 Jan 2017 12:47:14 -0500
From:   Boris Ostrovsky <boris.ostrovsky@...cle.com>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     jgross@...e.com, xen-devel@...ts.xenproject.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        vineethp@...zon.com, wei.liu2@...rix.com, paul.durrant@...rix.com,
        stable@...r.kernel.org
Subject: Re: [PATCH] xen-netfront: Delete rx_refill_timer in
 xennet_disconnect_backend()

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