linux-kernel - RE: [PATCH] r8152: Add __GFP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1922af354f7548f0878821b3f0692640@realtek.com>
Date:   Fri, 7 Apr 2023 06:24:20 +0000
From:   Hayes Wang <hayeswang@...ltek.com>
To:     Douglas Anderson <dianders@...omium.org>,
        "David S . Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>
CC:     André Apitzsch <git@...tzsch.eu>,
        Bjørn Mork <bjorn@...k.no>,
        David Ober <dober6023@...il.com>,
        Jean-Francois Le Fillatre <jflf_kernel@....com>,
        "Sven van Ashbrook" <svenva@...omium.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH] r8152: Add __GFP_NOWARN to big allocations

> From: Douglas Anderson <dianders@...omium.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@...omium.org>

Acked-by: Hayes Wang <hayeswang@...ltek.com>

Best Regards,
Hayes