linux-kernel - Re: [PATCH v6 1/2] dma/contiguous: Add helper to test reserved memory type

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: <8b36f958-3406-421d-ab94-5e49f911f92e@ti.com>
Date: Wed, 9 Jul 2025 10:55:40 -0500
From: Andrew Davis <afd@...com>
To: Maxime Ripard <mripard@...nel.org>, Rob Herring <robh@...nel.org>,
        Saravana Kannan <saravanak@...gle.com>,
        Sumit Semwal
	<sumit.semwal@...aro.org>,
        Benjamin Gaignard
	<benjamin.gaignard@...labora.com>,
        Brian Starkey <Brian.Starkey@....com>,
        John Stultz <jstultz@...gle.com>,
        "T.J. Mercier" <tjmercier@...gle.com>,
        Christian König <christian.koenig@....com>,
        Krzysztof
 Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Marek
 Szyprowski <m.szyprowski@...sung.com>,
        Robin Murphy <robin.murphy@....com>
CC: Jared Kangas <jkangas@...hat.com>,
        Mattijs Korpershoek
	<mkorpershoek@...nel.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-media@...r.kernel.org>, <dri-devel@...ts.freedesktop.org>,
        <linaro-mm-sig@...ts.linaro.org>, <iommu@...ts.linux.dev>
Subject: Re: [PATCH v6 1/2] dma/contiguous: Add helper to test reserved memory
 type

On 7/9/25 7:44 AM, Maxime Ripard wrote:
> A given reserved-memory region can be of multiple types.
> 
> We have currently four types defined in the tree: contiguous, backed by
> CMA, coherent and swiotlb, backed by their respective allocators, and a
> platform-specific one for tegra.
> 
> However, some users, like dma-buf heaps, might be interested in the
> exact type of a reserved memory region they are getting. It would thus
> be useful to have helpers to test if a given region is of a given type.
> 
> Since we only care about CMA for now though, let's create one for CMA
> only.
> 
> Signed-off-by: Maxime Ripard <mripard@...nel.org>
> ---
>   include/linux/dma-map-ops.h | 13 +++++++++++++
>   kernel/dma/contiguous.c     |  7 +++++++
>   2 files changed, 20 insertions(+)
> 
> diff --git a/include/linux/dma-map-ops.h b/include/linux/dma-map-ops.h
> index f48e5fb88bd5dd346094bbf2ce1b79e5f5bfe1a6..ea646acb6367bd062619b337013db221749f85ab 100644
> --- a/include/linux/dma-map-ops.h
> +++ b/include/linux/dma-map-ops.h
> @@ -153,10 +153,23 @@ static inline void dma_free_contiguous(struct device *dev, struct page *page,
>   {
>   	__free_pages(page, get_order(size));
>   }
>   #endif /* CONFIG_DMA_CMA*/
>   
> +#if defined(CONFIG_DMA_CMA) && defined(CONFIG_OF_RESERVED_MEM)
> +struct reserved_mem;
> +
> +bool of_reserved_mem_is_contiguous(const struct reserved_mem *rmem);
> +#else
> +struct reserved_mem;
> +
> +static inline bool of_reserved_mem_is_contiguous(const struct reserved_mem *rmem)
> +{
> +	return false;
> +}
> +#endif
> +

Should this all go in linux/of_reserved_mem.h?

>   #ifdef CONFIG_DMA_DECLARE_COHERENT
>   int dma_declare_coherent_memory(struct device *dev, phys_addr_t phys_addr,
>   		dma_addr_t device_addr, size_t size);
>   void dma_release_coherent_memory(struct device *dev);
>   int dma_alloc_from_dev_coherent(struct device *dev, ssize_t size,
> diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
> index 8df0dfaaca18eeb0a20145512ba64425d2e7601e..ace4982e928e404315cf38551e1596f7ed445156 100644
> --- a/kernel/dma/contiguous.c
> +++ b/kernel/dma/contiguous.c
> @@ -493,6 +493,13 @@ static int __init rmem_cma_setup(struct reserved_mem *rmem)
>   		&rmem->base, (unsigned long)rmem->size / SZ_1M);
>   
>   	return 0;
>   }
>   RESERVEDMEM_OF_DECLARE(cma, "shared-dma-pool", rmem_cma_setup);
> +
> +bool of_reserved_mem_is_contiguous(const struct reserved_mem *rmem)

Needing to check where the reserved mem comes from seems wrong, it hints
that the reserved mem region drivers, like this one, are not in full control
of their regions. Instead of looping over all the regions in DT in the next
patch and searching for the owner, how about the owner (this driver) call
into __add_cma_heap() if it chooses to expose the region in that way.

(I know RESERVEDMEM_OF_DECLARE callbacks are done very early and the CMA-Heap
driver might not be able to deal with adding heaps at this point, so maybe
keeping a table the heaps driver can later iterate over would also work).

Andrew

> +{
> +	return rmem->ops == &rmem_cma_ops;
> +}
> +EXPORT_SYMBOL_GPL(of_reserved_mem_is_contiguous);
> +
>   #endif
>