From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: dma-buf: heaps: system: add an option to allocate explicitly decrypted memory Date: Tue, 24 Feb 2026 10:16:38 +1000 Message-ID: In-Reply-To: <20260223095136.225277-1-jiri@resnulli.us> References: <20260223095136.225277-1-jiri@resnulli.us> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Overall Series Review Subject: dma-buf: heaps: system: add an option to allocate explicitly decrypted memory Author: Jiri Pirko Patches: 4 Reviewed: 2026-02-24T10:16:38.464553 --- This 2-patch series adds support for explicitly decrypted memory allocations in confidential computing (CoCo) VMs (AMD SEV, Intel TDX). Patch 1 introduces a new DMA attribute `DMA_ATTR_CC_DECRYPTED` that lets the DMA direct mapping path skip swiotlb bounce buffering for memory the caller has already decrypted. Patch 2 adds a new `system_cc_decrypted` dma-buf heap that allocates pages, decrypts them via `set_memory_decrypted()`, and makes them available to userspace and DMA importers with the correct page protections and DMA attributes. The architectural approach in v2 (a separate heap rather than a flag on the existing heap) is cleaner and was requested by reviewers. The series is well-motivated and the commit messages are thorough and accurate. There is one concrete bug in the error handling path of the allocation function in patch 2: when page decryption fails partway through the sg_table, the cleanup path attempts to re-encrypt pages that were never decrypted, which could cause unnecessary page leaks on CoCo VMs. There are also leftover UAPI header changes from v1 that appear unnecessary in v2. The `dma_direct_unmap_phys` function is not updated in patch 1, which is worth discussing even if it is likely benign. --- Generated by Claude Code Patch Reviewer