linux-kernel - Re: [PATCH 3/3] dma/pool: Avoid allocating redundant pools

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: <aWb51ntBtrJCwO6I@MiWiFi-R3L-srv>
Date: Wed, 14 Jan 2026 10:05:10 +0800
From: Baoquan He <bhe@...hat.com>
To: Robin Murphy <robin.murphy@....com>
Cc: m.szyprowski@...sung.com, akpm@...ux-foundation.org, vbabka@...e.cz,
	david@...nel.org, iommu@...ts.linux-foundation.org,
	linux-mm@...ck.org, vladimir.kondratiev@...ileye.com,
	s-adivi@...com, linux-kernel@...r.kernel.org,
	lorenzo.stoakes@...cle.com, Liam.Howlett@...cle.com,
	rppt@...nel.org, surenb@...gle.com, mhocko@...e.com,
	jackmanb@...gle.com, hannes@...xchg.org, ziy@...dia.com
Subject: Re: [PATCH 3/3] dma/pool: Avoid allocating redundant pools

On 01/13/26 at 04:14pm, Robin Murphy wrote:
> On 2026-01-13 10:16 am, Baoquan He wrote:
> > On 01/12/26 at 03:46pm, Robin Murphy wrote:
> > > On smaller systems, e.g. embedded arm64, it is common for all memory
> > > to end up in ZONE_DMA32 or even ZONE_DMA. In such cases it is redundant
> > 
> > This is true and the whole series looks great to me. Do we need adjust
> > warn_alloc() to handle empty DMA32 zone too like empty DMA zone case?
> 
> Hmm, I'd be inclined to think that if nobody's complaining already then we
> can probably just leave it as-is. A GFP_DMA32 allocation won't OOM unless
> *both* ZONE_DMA32 and ZONE_DMA are empty, right? At that point I'd imagine
> it's a bit more significant if someone who wants DMA32 memory can't have any
> - don't we have a mechanism for reserving some "low" memory for kdump for
> pretty much this exact reason?
> 
> A special case for when ZONE_DMA is tiny such that GFP_DMA can be expected
> to fail often seems fair, but in general I'd expect that if GFP_DMA32 starts
> failing then it's more a sign of a genuine mismatch between the kernel's
> expectations and the system configuration.

Makes sense to me. I remember someone plans to take off both DMA and DMA32 zone
in linux kernel, but that might not happen soon.