openwrt/target/linux/generic/backport-5.15/795-v6.3-06-r8152-Add-__GFP_NOWARN-to-big-allocations.patch

56 lines
1.9 KiB
Diff
Raw Normal View History

kernel: backport fixes for realtek r8152 Fixes issues with RTL8156 2.5G USB adapters - # ethtool eth1 Settings for eth1: Supported ports: [ ] Supported link modes: Not reported Supported pause frame use: No Supports auto-negotiation: No Supported FEC modes: Not reported Advertised link modes: Not reported Advertised pause frame use: No Advertised auto-negotiation: No Advertised FEC modes: Not reported Speed: 2500Mb/s Duplex: Half Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: off MDI-X: Unknown Current message level: 0x00000007 (7) drv probe link Link detected: yes - # - r8152: break the loop when the budget is exhausted - r8152: Block future register access if register access fails - r8152: Rename RTL8152_UNPLUG to RTL8152_INACCESSIBLE - r8152: add vendor/device ID pair for D-Link DUB-E250 - r8152: try to use a normal budget - r8152: set bp in bulk - r8152: adjust generic_ocp_write function - r8152: fix the autosuspend doesn't work - r8152: Add __GFP_NOWARN to big allocations - r8152: reduce the control transfer of rtl8152_get_version() - r8152: remove rtl_vendor_mode function - r8152: avoid to change cfg for all devices - r8152: add USB device driver for config selection - r8152: use napi_gro_frags - cdc_ether: no need to blacklist any r8152 devices - cdc_ether: add u-blox 0x1313 composition Build system: x86_64 Build-tested: bcm2711, rockchip, x86/64 Run-tested: bcm2711/RPi4B, rockchip/nanopi r2s, x86/64 Signed-off-by: Marty Jones <mj8263788@gmail.com>
2023-11-28 18:27:18 +00:00
From 5cc33f139e11b893ff6dc60d8a0ae865a65521ac Mon Sep 17 00:00:00 2001
From: Douglas Anderson <dianders@chromium.org>
Date: Thu, 6 Apr 2023 17:14:26 -0700
Subject: [PATCH] r8152: Add __GFP_NOWARN to big allocations
When memory is a little tight on my system, it's pretty easy to see
warnings that look like this.
ksoftirqd/0: page allocation failure: order:3, mode:0x40a20(GFP_ATOMIC|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0
...
Call trace:
dump_backtrace+0x0/0x1e8
show_stack+0x20/0x2c
dump_stack_lvl+0x60/0x78
dump_stack+0x18/0x38
warn_alloc+0x104/0x174
__alloc_pages+0x588/0x67c
alloc_rx_agg+0xa0/0x190 [r8152 ...]
r8152_poll+0x270/0x760 [r8152 ...]
__napi_poll+0x44/0x1ec
net_rx_action+0x100/0x300
__do_softirq+0xec/0x38c
run_ksoftirqd+0x38/0xec
smpboot_thread_fn+0xb8/0x248
kthread+0x134/0x154
ret_from_fork+0x10/0x20
On a fragmented system it's normal that order 3 allocations will
sometimes fail, especially atomic ones. The driver handles these
failures fine and the WARN just creates spam in the logs for this
case. The __GFP_NOWARN flag is exactly for this situation, so add it
to the allocation.
NOTE: my testing is on a 5.15 system, but there should be no reason
that this would be fundamentally different on a mainline kernel.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Hayes Wang <hayeswang@realtek.com>
Link: https://lore.kernel.org/r/20230406171411.1.I84dbef45786af440fd269b71e9436a96a8e7a152@changeid
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
drivers/net/usb/r8152.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1944,7 +1944,7 @@ static struct rx_agg *alloc_rx_agg(struc
if (!rx_agg)
return NULL;
- rx_agg->page = alloc_pages(mflags | __GFP_COMP, order);
+ rx_agg->page = alloc_pages(mflags | __GFP_COMP | __GFP_NOWARN, order);
if (!rx_agg->page)
goto free_rx;