| Message ID | 20230406171411.1.I84dbef45786af440fd269b71e9436a96a8e7a152@changeid (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 5cc33f139e11b893ff6dc60d8a0ae865a65521ac |
| Headers | show |
| Series | r8152: Add __GFP_NOWARN to big allocations | expand |
> From: Douglas Anderson <dianders@chromium.org> [...] > 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> Best Regards, Hayes
Hello: This patch was applied to netdev/net.git (main) by Jakub Kicinski <kuba@kernel.org>: On Thu, 6 Apr 2023 17:14:26 -0700 you wrote: > 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 > > [...] Here is the summary with links: - r8152: Add __GFP_NOWARN to big allocations https://git.kernel.org/netdev/net/c/5cc33f139e11 You are awesome, thank you!
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index decb5ba56a25..0fc4b959edc1 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -1943,7 +1943,7 @@ static struct rx_agg *alloc_rx_agg(struct r8152 *tp, gfp_t mflags) 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;
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> --- drivers/net/usb/r8152.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)