On Fri, Sep 18, 2026 at 05:23:32PM +0200, Christian König wrote:
On 9/18/26 17:16, Catalin Marinas wrote:
quoted
First, none of the DMA-BUF maintainers have been cc'ed. It might be fine
for an RFC but this series got to version 6. We need their feedback.
Yeah, thanks for doing this.
quoted
On Fri, Sep 04, 2026 at 04:04:50PM +0530, Aneesh Kumar K.V (Arm) wrote:
quoted
The system heap can allocate buffers that are decrypted and shared with the
host. For confidential-computing guests, those shared buffers must cover
whole shared-buffer granule; otherwise a userspace mmap of the dma-buf may
expose only part of a host-managed granule and allow unintended access to
adjacent private memory.
Require cc-shared system-heap allocations to have a size aligned to
mem_cc_shared_granule_size(), and allocate pages at least as large as the
required granule. Keep the allocation bounded by the existing heap orders,
but fall back to an exact minimum-order allocation when the required
granule is not one of the preferred heap orders.
Uff, I don't think we can do that.
That is massively platform specific behavior in a non platform
specific code.
What we really need is an allocator API that does all this for the caller.
It has been pointed out a few times, Aneesh maybe you need to try to
tackle that?
dmabuf heap just wants
'allocate me an array of shared folios totaling XX bytes'
Arch code can figure out how to do it. If some ARM configs only give
order 4 folios or whatever then dmabuf heap doesn't care.
And solve the double/triple zeroing problem.
Jason