net: macb: Fix lost RX packet wakeup race in NAPI receive
stable inclusion from stable-v5.10.106 commit 0c6eeaf8c168c8f48fc89c2795741f655d00ec5c bugzilla: https://gitee.com/openeuler/kernel/issues/I573US Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0c6eeaf8c168c8f48fc89c2795741f655d00ec5c -------------------------------- commit 0bf476fc upstream. There is an oddity in the way the RSR register flags propagate to the ISR register (and the actual interrupt output) on this hardware: it appears that RSR register bits only result in ISR being asserted if the interrupt was actually enabled at the time, so enabling interrupts with RSR bits already set doesn't trigger an interrupt to be raised. There was already a partial fix for this race in the macb_poll function where it checked for RSR bits being set and re-triggered NAPI receive. However, there was a still a race window between checking RSR and actually enabling interrupts, where a lost wakeup could happen. It's necessary to check again after enabling interrupts to see if RSR was set just prior to the interrupt being enabled, and re-trigger receive in that case. This issue was noticed in a point-to-point UDP request-response protocol which periodically saw timeouts or abnormally high response times due to received packets not being processed in a timely fashion. In many applications, more packets arriving, including TCP retransmissions, would cause the original packet to be processed, thus masking the issue. Fixes: 02f7a34f ("net: macb: Re-enable RX interrupt only when RX is done") Cc: stable@vger.kernel.org Co-developed-by:Scott McNutt <scott.mcnutt@siriusxm.com> Signed-off-by:
Loading
Please sign in to comment