linux-kernel - Re: [PATCH] dma-mapping: Stub out dma_{alloc,free,map}

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: <20250617044833.GE1824@lst.de>
Date: Tue, 17 Jun 2025 06:48:33 +0200
From: Christoph Hellwig <hch@....de>
To: Arnd Bergmann <arnd@...db.de>
Cc: James Clark <james.clark@...aro.org>, Christoph Hellwig <hch@....de>,
	Mark Brown <broonie@...nel.org>,
	Vladimir Oltean <olteanv@...il.com>, oe-kbuild-all@...ts.linux.dev,
	Larisa Grigore <larisa.grigore@....com>,
	Frank Li <Frank.li@....com>, linux-spi@...r.kernel.org,
	imx@...ts.linux.dev, linux-kernel@...r.kernel.org,
	kernel test robot <lkp@...el.com>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Robin Murphy <robin.murphy@....com>, iommu@...ts.linux.dev
Subject: Re: [PATCH] dma-mapping: Stub out dma_{alloc,free,map}_pages() API

On Mon, Jun 16, 2025 at 03:48:50PM +0200, Arnd Bergmann wrote:
> As far as I can tell, the difference here is that the
> dma_alloc_coherent()/dma_free_coherent() calls all get stubbed
> out, so the 827 drivers using those can all build cleanly on
> mk68knommu, shnommu and UML, while dma_alloc_noncoherent()/
> dma_free_noncoherent() are only used on 15 files that are all
> guarded by some other Kconfig dependency at the moment and won't
> build on the those platforms.

Yes, dma_alloc_coherent is from a time where stubbing out was
still very common.

> I agree that it would be best to treat the coherent/noncoherent
> cases the same, and I also think the existing stubs are a bit
> silly, but just removing them would likely require fixing
> hundreds of drivers with added Kconfig or IS_ENABLED() checks.

I doubt it's that many, as most drivers and even subsystems simply
depend on DMA.  There's probably at most a few dozen drivers
supporting DMA but not requiring it.

> Maybe we can actually remove CONFIG_NO_DMA/CONFIG_HAS_DMA
> entirely and remove all the checks for CONFIG_HAS_DMA? 
> My guess is that this would only lead to a small code size
> increase on the affected targets, but since they are not
> actually trying to do DMA, and they all have a very limited
> set of drivers they actually use, it won't break existing
> code.

Except for uml, the CONFIG_NO_DMA configs are usually very resource
constraint, so I don't think that's a good idea.