Re: [RFC PATCH 2/7] dma-direct: use DMA_ATTR_CC_DECRYPTED in alloc/free paths

[Jason Gunthorpe <jgg@ziepe.ca>]

On Sat, Apr 18, 2026 at 11:57:42AM +0530, Aneesh Kumar K.V wrote:
> Aneesh Kumar K.V <aneesh.kumar@kernel.org> writes:
> 
> > Jason Gunthorpe <jgg@ziepe.ca> writes:
> >
> >> On Fri, Apr 17, 2026 at 02:28:55PM +0530, Aneesh Kumar K.V (Arm) wrote:
> >>> Propagate force_dma_unencrypted() into DMA_ATTR_CC_DECRYPTED in the
> >>> dma-direct allocation path and use the attribute to drive the related
> >>> decisions.
> >>> 
> >>> This updates dma_direct_alloc(), dma_direct_free(), and
> >>> dma_direct_alloc_pages() to fold the forced unencrypted case into attrs.
> >>> 
> >>> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
> >>> ---
> >>>  kernel/dma/direct.c | 34 ++++++++++++++++++++++++++--------
> >>>  1 file changed, 26 insertions(+), 8 deletions(-)
> >>> 
> >>> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> >>> index c2a43e4ef902..3932033f4d8c 100644
> >>> --- a/kernel/dma/direct.c
> >>> +++ b/kernel/dma/direct.c
> >>> @@ -201,16 +201,21 @@ void *dma_direct_alloc(struct device *dev, size_t size,
> >>>  		dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
> >>>  {
> >>>  	bool remap = false, set_uncached = false;
> >>> -	bool mark_mem_decrypt = true;
> >>> +	bool mark_mem_decrypt = !!(attrs & DMA_ATTR_CC_DECRYPTED);
> >>>  	struct page *page;
> >>
> >> This is changing the API, I think it should not be hidden in a patch
> >> like this, also not sure it even makes sense..
> >>
> >> DMA_ATTR_CC_DECRYPTED only says the address passed to mapping is
> >> decrypted. It is like DMA_ATTR_MMIO in this regard.
> >>
> >> Passing it to dma_alloc_attrs() is currently invalid, and I think it
> >> should remain invalid, or at least this new behavior introduced in its
> >> own patch deliberately.
> >>
> 
> Thinking about this further, I am wondering why you consider passing
> DMA_ATTR_CC_DECRYPTED invalid.

It doesn't do that today. My point is if you want to add then then do
it in its own patch and justify what it is for..

I cannot think of a reason for anything to want to do this. The
purpose of decrypted memory is to allow a T=0 device to access it and
you cannot take memory allocated by dma_alloc and pass it to some
other device as a matter of API. So it would be *really* suspicious if
some driver wanted this.

> How about making the change below so that we only prevent
> dma_alloc_attrs() from accepting DMA_ATTR_CC_DECRYPTED?

Yeah, that is what I was trying to say. No issue with it using it
inside I think.

Jason