realtek: avoid interrupt storm on mass packet receive

realtek: avoid interrupt storm on mass packet receive

RTL83xx devices have two types of receive interrupts for each of its
8 rings. One for packet received and another for ring overflow. When
the switch is flooded with incoming packets the receive handler will
disable the packet receive notification but still keeps the overflow
notification enabled. While the receive path "slowly" processes the
received packets each new packet triggers the overflow IRQ again. The
device becomes unresponsive and eventually produces messages like:

[18441.709764] rcu: Stack dump where RCU GP kthread last ran:
[18441.727892] Sending NMI from CPU 1 to CPUs 0:
[18441.742300] NMI backtrace for cpu 0 skipped: idling at 0x8080e994
[18415.251700] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[18415.271350] rcu:     0-...!: (0 ticks this GP) idle=d740/0/0x0 ...
[18415.303046] rcu:     (detected by 1, t=6004 jiffies, g=230925, ...
[18415.326095] Sending NMI from CPU 1 to CPUs 0:
[18415.340540] NMI backtrace for cpu 0

Fix this issue by always disabling receive and overflow interrupts at
the same time.

Test with hping3 --udp -p 5021 -d 1400 --flood 192.168.2.72

Before (3sec run):
[183260.324846] rtl838x-eth 1b00a300.ethernet eth0: RX buffer overrun: status 0x101, mask: 0x7ffeff
[183260.340524] rtl838x-eth 1b00a300.ethernet eth0: RX buffer overrun: status 0x1, mask: 0x7ffeff
[183260.345799] net_ratelimit: 489997 callbacks suppressed

After (3 sec run):
[  373.981479] rtl838x-eth 1b00a300.ethernet eth0: rx ring overrun: status 0x101, mask: 0x7fffff
[  374.031118] rtl838x-eth 1b00a300.ethernet eth0: rx ring overrun: status 0x101, mask: 0x7fffff
[  377.919996] net_ratelimit: 34 callbacks suppressed

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19365
(cherry picked from commit 963ee6ac3fc287328ce5a1e49d7f5910b060ec96)
Signed-off-by: Felix Baumann <felix.bau@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19891
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>