Re: [PATCH v2] dma/pool: respect __GFP_NOWARN in dma_alloc_from_pool()

[Robin Murphy]

On 2026-01-13 8:45 am, Adivi, Sai Sree Kartheek wrote:
> On 1/12/2026 7:43 PM, Robin Murphy wrote:
> > On 2026-01-12 10:47 am, Sai Sree Kartheek Adivi wrote:
> > > Currently, dma_alloc_from_pool() unconditionally warns and dumps a stack
> > > trace when an allocation fails.
> > >
> > > This prevents callers from using the __GFP_NOWARN flag to suppress error
> > > messages, breaking the expectation that this flag will silence
> > > allocation failure logs.
> >
> > This is not an "allocation failure" in that sense, though. It's not 
> > like the caller has opportunistically requested a large allocation, 
> > and is happy to try again with a smaller size - if someone has asked 
> > for an allocation in atomic context that can only be satisfied from an 
> > atomic pool, and there is no atomic pool at all, that points at 
> > something being more fundamentally wrong with the system, in a manner 
> > that the caller probably isn't expecting.
> >
> > Under what circumstances are you seeing the warning without things 
> > being totally broken anyway?
>
> Hi Robin,
>
> To clarify this specific circumstance: I am testing a dmaengine driver 
> using the in-kernel crypto test framework, which generates a synthetic 
> high load.
>
> The driver attempts to allocate descriptors in an atomic context using 
> GFP_NOWAIT. When the atomic pool is exhausted under this stress, we want 
> to return NULL silently so the driver can gracefully handle the back 
> pressure by either:
> 1. Falling back to non-DMA (PIO) mode, or
> 2. Triggering dmaengine_synchronize() to allow async threads to actually 
> free up used descriptors.
>
> Since the driver implements a valid fallback for this exhaustion, the 
> current unconditional WARN generates false alarms in the log.
>
> This change would align dma_pool behavior with the core page allocator. 
> For example, warn_alloc() in mm/page_alloc.c explicitly checks for 
> __GFP_NOWARN to allow callers to suppress failure messages when they 
> have a recovery path.

Oof, apologies - looking again at the code in context, now I finally see 
what the bug really is: this warning still serves its original purpose, 
but due to the refactoring in 9420139f516d indeed it's *also* ended up 
in the path where the correct pool was found but was simply unable to 
satisfy the allocation. I agree that's not right - we never used to warn 
on an actual gen_pool_alloc() failure either way, so whether we have a 
suppressible (and more appropriately worded) warning for that condition 
I'm not too fussed. However, what I don't want to do is go too far the 
other way and lose the intended message when the requested allocation 
flags could *never* be satisfied by the current system configuration.

What distracted me is that I think the latter can be falsely reported 
for __GFP_DMA32 on a system where CONFIG_ZONE_DMA32 is enabled, but all 
the memory is in ZONE_DMA, so I was wondering whether your system was in 
that situation. The other series I sent should fix that.

> However if you feel the atomic pool should strictly not support silent 
> failures, the alternative would be for the driver to manually track its 
> own usage against the pool size and stop allocating before hitting the 
> limit. We prefer the __GFP_NOWARN approach as it avoids duplicating 
> resource tracking logic in the driver.

Eww, no, that would be far worse :) Just untangling the "failed to 
allocate from a valid pool" condition from the "failed to find an 
appropriate pool at all" one in this code is fine!

Thanks,
Robin.