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
| ||
|
Message-ID: <20231024124457.2a8fdf23@meshulam.tesarici.cz> Date: Tue, 24 Oct 2023 12:44:57 +0200 From: Petr Tesařík <petr@...arici.cz> To: Florian Fainelli <f.fainelli@...il.com> Cc: Ben Greear <greearb@...delatech.com>, netdev <netdev@...r.kernel.org>, Christoph Hellwig <hch@....de> Subject: Re: swiotlb dyn alloc WARNING splat in wireless-next. Hi Florian, thank you for your report! On Mon, 23 Oct 2023 18:01:46 -0700 Florian Fainelli <f.fainelli@...il.com> wrote: > +Christoph, Petr > > On 10/22/2023 11:48 AM, Ben Greear wrote: > > Hello, > > > > I saw this in a system with 16GB of RAM running a lot of wifi traffic > > on 16 radios. System appears to mostly be working OK, so not sure if it is > > a real problem or not. > > > > [76171.488627] WARNING: CPU: 2 PID: 30169 at mm/page_alloc.c:4402 > > __alloc_pages+0x19c/0x200 This is a WARN_ON_ONCE_GFP(order > MAX_ORDER, gfp), and the allocation fails. The dynamic SWIOTLB pool allocator will then reduce the requested size by half until allocation succeeds (or fails even for minimum size). That's why your system behaves normally. However, starting with a request that is larger than MAX_ORDER is silly, especially since this is the default if you build your kernel with CONFIG_SWIOTLB_DYNAMIC=y and boot it without any swiotlb= parameter. It makes sense to clamp the requested size to MAX_ORDER before the first loop iteration. I'm going to send a patch. Petr T
Powered by blists - more mailing lists