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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <9788991a-ac37-4fde-81db-c55035d00f27@app.fastmail.com>
Date: Mon, 16 Jun 2025 15:48:50 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "James Clark" <james.clark@...aro.org>, "Christoph Hellwig" <hch@....de>
Cc: "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 15:23, James Clark wrote:
> On 16/06/2025 2:19 pm, Christoph Hellwig wrote:
>> On Mon, Jun 16, 2025 at 02:15:56PM +0100, James Clark wrote:
>>>> Yes it does, it has a few modes that don't require it. Presumably we can't
>>>> just add a depends into the kconfig for all devices because they might not
>>>> be using DMA.
>>>
>>> *for all the different variants of spi-fsl-dpsi devices I mean
>> 
>> This is drivers/spi/spi-fsl-dspi.c?
>> 
>> Yes, looks like it is one of those rare devices supporting a DMA and
>> non-DMA mode.  But everything seems nicely guarded off using
>> "dspi->devtype_data->trans_mode == DSPI_DMA_MODE" checks there.  So
>> wrap them into a little helper using IS_ENABLED(CONFIG_HAS_DMA) and
>> everything should be sorted out.
>
> Sure, I don't mind doing it.
>
> But separately to that, I still think making the stubs consistent would 
> save people a lot of time diagnosing build failures if they switch 
> existing code to any of those 3 functions. Principle of Least 
> Astonishment and all that.

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.

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.

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.

    Arnd