[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20190916.214053.1979513954122379431.davem@davemloft.net>
Date: Mon, 16 Sep 2019 21:40:53 +0200 (CEST)
From: David Miller <davem@...emloft.net>
To: sameehj@...zon.com
Cc: netdev@...r.kernel.org, dwmw@...zon.com, zorik@...zon.com,
matua@...zon.com, saeedb@...zon.com, msw@...zon.com,
aliguori@...zon.com, nafea@...zon.com, gtzalik@...zon.com,
netanel@...zon.com, alisaidi@...zon.com, benh@...zon.com,
akiyano@...zon.com
Subject: Re: [PATCH V1 net] net: ena: don't wake up tx queue when down
From: <sameehj@...zon.com>
Date: Sun, 15 Sep 2019 17:29:44 +0300
> From: Sameeh Jubran <sameehj@...zon.com>
>
> There is a race condition that can occur when calling ena_down().
> The ena_clean_tx_irq() - which is a part of the napi handler -
> function might wake up the tx queue when the queue is supposed
> to be down (during recovery or changing the size of the queues
> for example) This causes the ena_start_xmit() function to trigger
> and possibly try to access the destroyed queues.
>
> The race is illustrated below:
>
> Flow A: Flow B(napi handler)
> ena_down()
> netif_carrier_off()
> netif_tx_disable()
> ena_clean_tx_irq()
> netif_tx_wake_queue()
> ena_napi_disable_all()
> ena_destroy_all_io_queues()
>
> After these flows the tx queue is active and ena_start_xmit() accesses
> the destroyed queue which leads to a kernel panic.
>
> fixes: 1738cd3ed342 (net: ena: Add a driver for Amazon Elastic Network Adapters (ENA))
>
> Signed-off-by: Sameeh Jubran <sameehj@...zon.com>
Applied.
Powered by blists - more mailing lists