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

[Jiri Pirko]

Sat, Apr 18, 2026 at 06:06:17PM +0200, jgg@xxxxxxxx wrote:
>On Sat, Apr 18, 2026 at 11:57:42AM +0530, Aneesh Kumar K.V wrote:
>> Aneesh Kumar K.V <aneesh.kumar@xxxxxxxxxx> writes:
>> 
>> > Jason Gunthorpe <jgg@xxxxxxxx> 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@xxxxxxxxxx>
>> >>> ---
>> >>>  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.

Agreed. I think that allowing map with DMA_ATTR_CC_DECRYPTED for those
devices would need very clear usecase described alongside.


>
>> 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