On 2021-10-21 10:06, Christoph Hellwig wrote:
When dma_set_decrypted fails for the remapping case in dma_direct_alloc
we also need to unmap the pages before freeing them.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
kernel/dma/direct.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index d4d54af31a341..2fef8dd401fe9 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -230,7 +230,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
if (!ret)
goto out_free_pages;
if (dma_set_decrypted(dev, ret, size))
I was going to say just stick the vunmap() in here to avoid adding yet
more messy conditionals, but one rabbit hole later... Given that the
dma_pgprot() we've just passed to dma_common_pages_remap() already adds
in pgprot_decrypted, why is this even here at all?
Robin.
- goto out_free_pages;
+ goto out_unmap_pages;
memset(ret, 0, size);
goto done;
}
@@ -266,6 +266,9 @@ void *dma_direct_alloc(struct device *dev, size_t size,
/* If memory cannot be re-encrypted, it must be leaked */
if (dma_set_encrypted(dev, page_address(page), size))
return NULL;
+out_unmap_pages:
+ if (IS_ENABLED(CONFIG_DMA_REMAP) && is_vmalloc_addr(ret))
+ vunmap(ret);
out_free_pages:
__dma_direct_free_pages(dev, page, size);
return NULL;
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
