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

Aneesh Kumar K.V
2026-04-18T06:27:49Z

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. That could be one way for a T=1 device to
request decrypted memory. We do not fully support that today, but is
there any specific reason you object to allowing DMA_ATTR_CC_DECRYPTED
in the allocation paths?

I understand that DMA_ATTR_CC_DECRYPTED is currently used to describe
already allocated memory, but extending it to also indicate a DMA
address attribute would simplify the allocation path. We could then
avoid passing a separate unencrypted/decrypted flag to the various
functions that already take an attrs argument in the allocation path.

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

modified kernel/dma/direct.c
@@ -204,11 +204,14 @@ 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 = !!(attrs & DMA_ATTR_CC_DECRYPTED);
+ bool mark_mem_decrypt = false;
bool allow_highmem = true;
struct page *page;
void *ret;

+ if (attrs & DMA_ATTR_CC_DECRYPTED)
+ return NULL;
+
if (force_dma_unencrypted(dev)) {
attrs |= DMA_ATTR_CC_DECRYPTED;
mark_mem_decrypt = true;
@@ -345,7 +348,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
void dma_direct_free(struct device *dev, size_t size,
void *cpu_addr, dma_addr_t dma_addr, unsigned long attrs)
{
- bool mark_mem_encrypted = !!(attrs & DMA_ATTR_CC_DECRYPTED);
+ bool mark_mem_encrypted = false;
unsigned int page_order = get_order(size);

/*

-aneesh