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(-)

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;
 
-- 
2.40.0.577.gac1e443424-goog

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!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

> 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