lkml.org 
[lkml]   [2023]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH] r8152: Add __GFP_NOWARN to big allocations
Date
> 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

\
 
 \ /
  Last update: 2023-04-07 08:26    [W:0.178 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site