linux-kernel - Re: [PATCH v2] usb: core: warn if a GFP zone flag is passed to hcd_buffer

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: <20250416124736.3ac2bd55@mordecai>
Date: Wed, 16 Apr 2025 12:47:36 +0200
From: Petr Tesarik <ptesarik@...e.com>
To: Oliver Neukum <oneukum@...e.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] usb: core: warn if a GFP zone flag is passed to
 hcd_buffer_alloc()

On Wed, 16 Apr 2025 10:45:19 +0200
Oliver Neukum <oneukum@...e.com> wrote:

> On 16.04.25 09:48, Petr Tesarik wrote:
> 
> > Oh, I do, and that's precisely why these GFP flags are no good. The
> > address (and other) constraints imposed by different buses may not
> > (and often do not) match any existing memory zone.  
> 
> True. So we currently have a non-portable series of flags.
> It would we better if we passed a hypothetical 'struct mem_constraint*'.
> But we don't for now.

We don't have this struct as such, but all required values are stored
directly or indirectly (dma_range_map) in struct device, which is
already passed around.

There's merely no mm API that could allocate based on these raw values,
so there are some ugly kludges to cope with most scenarios.

> > However, zone address ranges are determined statically at compile time,
> > or latest at boot time (e.g. arm64). It's too late to adjust the limits
> > when you hotplug a more constrained bus at run-time. And I haven't even
> > mentioned bus bridges which add a non-zero offset to the address...  
> 
> Yes. Hence the only time somebody would pass a flag like that would be
> on very arch specific code. That means that such a developer would be on
> his or her own. Hence I'd say the simplest solution is just to do nothing.

I have found no such thing in tree (with the exception of s390-specific
drivers, mentioned elsewhere in this thread). But whatever is possible
with a GFP flag is also possible by setting a bus limit.

If I stay with the USB buffer allocations, AFAICS the mem_flags
parameter should be used only for non-zone flags. If you specify,
GFP_DMA here, it will have no impact whatsoever on allocating DMA
buffers. It may unnecessarily allocate from the DMA zone for doing PIO.

Now I think I should really write an article for LWN to debunk some
myths about GFP_DMA.

HTH
Petr T