Re: [PATCH 05/10] dma-direct: factor out a helper for DMA_ATTR_NO_KERNEL_MAPPING allocations

[Robin Murphy <robin.murphy@arm.com>]

On 2021-10-21 10:06, Christoph Hellwig wrote:
> Split the code for DMA_ATTR_NO_KERNEL_MAPPING allocations into a separate
> helper to make dma_direct_alloc a little more readable.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Acked-by: David Rientjes <rientjes@google.com>
> ---
>   kernel/dma/direct.c | 31 ++++++++++++++++++++-----------
>   1 file changed, 20 insertions(+), 11 deletions(-)
> 
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index a6b6fe72af4d1..4ffdb524942a1 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -163,6 +163,24 @@ static void *dma_direct_alloc_from_pool(struct device *dev, size_t size,
>   	return ret;
>   }
>   
> +static void *dma_direct_alloc_no_mapping(struct device *dev, size_t size,
> +		dma_addr_t *dma_handle, gfp_t gfp)
> +{
> +	struct page *page;
> +
> +	page = __dma_direct_alloc_pages(dev, size, gfp & ~__GFP_ZERO);
> +	if (!page)
> +		return NULL;
> +
> +	/* remove any dirty cache lines on the kernel alias */
> +	if (!PageHighMem(page))
> +		arch_dma_prep_coherent(page, size);
> +
> +	/* return the page pointer as the opaque cookie */
> +	*dma_handle = phys_to_dma_direct(dev, page_to_phys(page));
> +	return page;
> +}
> +
>   void *dma_direct_alloc(struct device *dev, size_t size,
>   		dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
>   {
> @@ -175,17 +193,8 @@ void *dma_direct_alloc(struct device *dev, size_t size,
>   		gfp |= __GFP_NOWARN;
>   
>   	if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
> -	    !force_dma_unencrypted(dev) && !is_swiotlb_for_alloc(dev)) {
> -		page = __dma_direct_alloc_pages(dev, size, gfp & ~__GFP_ZERO);
> -		if (!page)
> -			return NULL;
> -		/* remove any dirty cache lines on the kernel alias */
> -		if (!PageHighMem(page))
> -			arch_dma_prep_coherent(page, size);
> -		*dma_handle = phys_to_dma_direct(dev, page_to_phys(page));
> -		/* return the page pointer as the opaque cookie */
> -		return page;
> -	}
> +	    !force_dma_unencrypted(dev) && !is_swiotlb_for_alloc(dev))

Hmm, does force_dma_unencrypted() actually matter if the caller doesn't 
want to access the buffer itself? Presumably any subsequent mmap() to 
userspace would still do the right thing?

Robin.

> +		return dma_direct_alloc_no_mapping(dev, size, dma_handle, gfp);
>   
>   	if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
>   	    !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
> 
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu