Re: [RFC PATCH v3 5/5] dma-mapping: Fix memory decryption issues

[Aneesh Kumar K . V]

Mostafa Saleh <smostafa@xxxxxxxxxx> writes:

> Fix 2 existing issues:
> 1) In case a device have a restricted DMA pool, memory will be
> decrypted (which is now returned in the state from swiotlb_alloc().
>
> Later the main function  will attempt to decrypt the memory if
> force_dma_unencrypted() is true.
>
> Which results in the memory being decrypted twice.
> Change that to only encrypt/decrypt memory that is not already
> decrypted as indicated in the new dma_page struct.
>

As discussed in the v2 email thread, we should address this by deciding
whether, for now, we treat all allocations from swiotlb pools as
unencrypted

https://lore.kernel.org/all/yq5aeckjbdrt.fsf@xxxxxxxxxx

>
> 2) Using phys_to_dma_unencrypted() is not enlighted about already
> decrypted memory and will use the wrong functions for that.
>

Can you split this into a separate patch? I’m finding it difficult to
understand what the issue is here. Adding the unencrypted flag multiple
times to an address is not a problem in itself. Even so, I still do not
follow when we would end up doing that.

At the interface level:
phys_to_dma should always return an encrypted address.
phys_to_dma_unencrypted should always return an unencrypted address.
phys_to_dma_direct should depend on the device state.


> Fixes: f4111e39a52a ("swiotlb: Add restricted DMA alloc/free support")
> Signed-off-by: Mostafa Saleh <smostafa@xxxxxxxxxx>
>

-aneesh