[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200212.094356.734697556409905980.davem@davemloft.net>
Date: Wed, 12 Feb 2020 09:43:56 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: firo.yang@...e.com
Cc: netdev@...r.kernel.org, pkaustub@...co.com, _govind@....com,
benve@...co.com, firogm@...il.com
Subject: Re: [PATCH 1/1] enic: prevent waking up stopped tx queues over
watchdog reset
From: Firo Yang <firo.yang@...e.com>
Date: Wed, 12 Feb 2020 06:09:17 +0100
> Recent months, our customer reported several kernel crashes all
> preceding with following message:
> NETDEV WATCHDOG: eth2 (enic): transmit queue 0 timed out
> Error message of one of those crashes:
> BUG: unable to handle kernel paging request at ffffffffa007e090
>
> After analyzing severl vmcores, I found that most of crashes are
> caused by memory corruption. And all the corrupted memory areas
> are overwritten by data of network packets. Moreover, I also found
> that the tx queues were enabled over watchdog reset.
>
> After going through the source code, I found that in enic_stop(),
> the tx queues stopped by netif_tx_disable() could be woken up over
> a small time window between netif_tx_disable() and the
> napi_disable() by the following code path:
> napi_poll->
> enic_poll_msix_wq->
> vnic_cq_service->
> enic_wq_service->
> netif_wake_subqueue(enic->netdev, q_number)->
> test_and_clear_bit(__QUEUE_STATE_DRV_XOFF, &txq->state)
> In turn, upper netowrk stack could queue skb to ENIC NIC though
> enic_hard_start_xmit(). And this might introduce some race condition.
>
> Our customer comfirmed that this kind of kernel crash doesn't occur over
> 90 days since they applied this patch.
>
> Signed-off-by: Firo Yang <firo.yang@...e.com>
Applied and queued up for -stable, thanks.
Powered by blists - more mailing lists