netdev - Re: swiotlb dyn alloc WARNING splat in wireless-next.

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] [day] [month] [year] [list]

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