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

[Aneesh Kumar K . V]

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

That is probably confusion on my side. I thought all the DMA attr can be
used on the alloc side to specify the attribute for DMA allocation
buffer. 

>
> Meaning, if you call dma_direct_alloc() force_dma_decrypted decides
> what setting DMA_ATTR_CC_DECRYPTED takes and it is EOPNOTSUPP if the
> user passes it in.
>

Sure, I can update the patchset to implement the above.

-aneesh