diff options
| author | Paolo Abeni <pabeni@redhat.com> | 2026-09-24 12:41:12 +0200 |
|---|---|---|
| committer | Paolo Abeni <pabeni@redhat.com> | 2026-09-24 12:41:13 +0200 |
| commit | 3cd204d4c66fd748edb7ddb072978ae4005c400f (patch) | |
| tree | 690f9612142447830592ec758b4a0e590adf90df /include/linux/debugobjects.h | |
| parent | 00efbbd40bd5fd92c67b7cf1aab8904fa59a96f6 (diff) | |
| parent | 43e746821f5f5afbbf68e388bf9fbe221e03bfca (diff) | |
Merge branch 'net-atl1c-atl1e-atl1-fix-soft-lockup-on-out-of-range-tx-consumer-index'
says:
====================
net: atl1c/atl1e/atl1: fix soft lockup on out-of-range tx consumer index
atl1c_clean_tx() reads a hardware-maintained tx consumer index and
walks a software index towards it:
while (next_to_clean != hw_next_to_clean) {
...
if (++next_to_clean == tpd_ring->count)
next_to_clean = 0;
}
next_to_clean only ever takes values in [0, tpd_ring->count). If the
hardware read returns a value outside that range - seen as 0xffff
while the PCIe link/MAC is resetting, e.g. during a neighboring
device's reboot - the loop condition can never become false, and the
NAPI thread spins forever. This produced a real soft lockup on
current hardware:
watchdog: BUG: soft lockup - CPU#12 stuck for 354s! [napi/eth%d-0]
RIP: 0010:atl1c_clean_tx+0x142/0x2d0 [atl1c]
Patch 1 fixes this in atl1c. atl1e and atl1 (atlx) share the exact
same loop shape, reading their own hardware-maintained consumer index
with no bounds check either, and are just as reachable from the same
kind of PCIe link event. Patches 2 and 3 apply the same guard to each.
====================
Link: https://patch.msgid.link/20260921091334.3571525-1-tamas@rimpianto.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Diffstat (limited to 'include/linux/debugobjects.h')
0 files changed, 0 insertions, 0 deletions
