linux-kernel - Re: [PATCH 0/3] dma-mapping: Improve atomic pool behaviour

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:
 <DU0PR09MB62984EFCC64DB724F3BC8CD8948EA@DU0PR09MB6298.eurprd09.prod.outlook.com>
Date: Tue, 13 Jan 2026 14:07:29 +0000
From: Vladimir Kondratiev <Vladimir.Kondratiev@...ileye.com>
To: Robin Murphy <robin.murphy@....com>, "m.szyprowski@...sung.com"
	<m.szyprowski@...sung.com>, "akpm@...ux-foundation.org"
	<akpm@...ux-foundation.org>, "vbabka@...e.cz" <vbabka@...e.cz>,
	"david@...nel.org" <david@...nel.org>
CC: "bhe@...hat.com" <bhe@...hat.com>, "iommu@...ts.linux-foundation.org"
	<iommu@...ts.linux-foundation.org>, "linux-mm@...ck.org"
	<linux-mm@...ck.org>, "s-adivi@...com" <s-adivi@...com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"lorenzo.stoakes@...cle.com" <lorenzo.stoakes@...cle.com>,
	"Liam.Howlett@...cle.com" <Liam.Howlett@...cle.com>, "rppt@...nel.org"
	<rppt@...nel.org>, "surenb@...gle.com" <surenb@...gle.com>, "mhocko@...e.com"
	<mhocko@...e.com>, "jackmanb@...gle.com" <jackmanb@...gle.com>,
	"hannes@...xchg.org" <hannes@...xchg.org>, "ziy@...dia.com" <ziy@...dia.com>
Subject: Re: [PATCH 0/3] dma-mapping: Improve atomic pool behaviour

> Hi all,
> 
> These days we have somewhat of a matrix of mm zones that may or may not
> exist and may or may not be empty, which the per-zone atomic pool logic
> doesn't actually handle all that well. It's not all that difficult to
> improve robustness and reduce redundancy, so that's what this series
> aims for.
> 
> I initially wrote this just because I happened to be looking through the
> boot log of one of my boards and had one of those out-of-the-blue
> realisations of "hang on, why *is* it allocating pools for zones it
> doesn't even have memory in?", but coincidentally, it seems that others
> happened to notice related aspects around the same time[1][2]. This is
> my attempt to sort it all out properly.
> 
> I guess this could go via either the dma-mapping or mm tree, whichever
> maintainers prefer.
> 
> Thanks,
> Robin.
> 
> 
> [1] Suspicious Link - Removed
> [2] Suspicious Link - Removed
> 
> Robin Murphy (3):
>   dma/pool: Improve pool lookup
>   mm_zone: Generalise has_managed_dma()
>   dma/pool: Avoid allocating redundant pools
> 
>  include/linux/mmzone.h |  9 +++++----
>  kernel/dma/pool.c      | 27 ++++++++++++++++++---------
>  mm/page_alloc.c        |  8 ++------
>  3 files changed, 25 insertions(+), 19 deletions(-)
> 
> --
> 2.34.1

Tested-by: Vladimir Kondratiev <vladimir.kondratiev@...ileye.com>

Tested on platform: upcoming Mobileye eyeq7h - risc-v platform with memory
mapped to 32Gbytes so DMA32 zone is empty