* [PATCH] r8152: Add __GFP_NOWARN to big allocations
@ 2023-04-07 0:14 Douglas Anderson
2023-04-07 6:24 ` Hayes Wang
2023-04-08 3:20 ` patchwork-bot+netdevbpf
0 siblings, 2 replies; 3+ messages in thread
From: Douglas Anderson @ 2023-04-07 0:14 UTC (permalink / raw)
To: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: Douglas Anderson, André Apitzsch, Bjørn Mork,
David Ober, Hayes Wang, Jean-Francois Le Fillatre,
Sven van Ashbrook, linux-kernel, linux-usb, netdev
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
^ permalink raw reply related [flat|nested] 3+ messages in thread
* RE: [PATCH] r8152: Add __GFP_NOWARN to big allocations
2023-04-07 0:14 [PATCH] r8152: Add __GFP_NOWARN to big allocations Douglas Anderson
@ 2023-04-07 6:24 ` Hayes Wang
2023-04-08 3:20 ` patchwork-bot+netdevbpf
1 sibling, 0 replies; 3+ messages in thread
From: Hayes Wang @ 2023-04-07 6:24 UTC (permalink / raw)
To: Douglas Anderson, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: André Apitzsch, Bjørn Mork, David Ober,
Jean-Francois Le Fillatre, Sven van Ashbrook,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] r8152: Add __GFP_NOWARN to big allocations
2023-04-07 0:14 [PATCH] r8152: Add __GFP_NOWARN to big allocations Douglas Anderson
2023-04-07 6:24 ` Hayes Wang
@ 2023-04-08 3:20 ` patchwork-bot+netdevbpf
1 sibling, 0 replies; 3+ messages in thread
From: patchwork-bot+netdevbpf @ 2023-04-08 3:20 UTC (permalink / raw)
To: Douglas Anderson
Cc: davem, edumazet, kuba, pabeni, git, bjorn, dober6023, hayeswang,
jflf_kernel, svenva, linux-kernel, linux-usb, netdev
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-04-08 3:20 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-04-07 0:14 [PATCH] r8152: Add __GFP_NOWARN to big allocations Douglas Anderson
2023-04-07 6:24 ` Hayes Wang
2023-04-08 3:20 ` patchwork-bot+netdevbpf
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).