summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorFiro Yang <firo.yang@suse.com>2020-02-12 06:09:17 +0100
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2020-02-28 15:39:11 +0100
commited2a26acbc04148ba396bbf11eb8e3fdcbf27a3b (patch)
tree06bfb4a75768e2087a76d7452fdd79f04d5a01f4 /include
parentb89e36cf28ba3a292884256d5afe85d94d0df061 (diff)
enic: prevent waking up stopped tx queues over watchdog reset
[ Upstream commit 0f90522591fd09dd201065c53ebefdfe3c6b55cb ] 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@suse.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions