Thread (39 messages) 39 messages, 8 authors, 5d ago

Re: [RFC PATCH v7 02/13] mm: Add an allocator for CoCo shared memory

From: Jason Gunthorpe <jgg@ziepe.ca>
Date: 2026-09-23 13:06:14
Also in: dri-devel, kvmarm, linux-coco, linux-iommu, linux-media, linux-mm, lkml

On Wed, Sep 23, 2026 at 11:40:36AM +0100, Catalin Marinas wrote:
The simplest is probably to always zero in the backend and ignore
__GFP_ZERO to the allocator. But it's probably only marginally smaller
than passing a CC_SHARED_ZERO flag down. Get codex to try this as well
and compare the diffstat.
For patch ordering I would convert to use the allocator first

The semantics of the new API should be clear

If you pass GFP_ZERO then the resulting allocated memory is zero

Otherwise the allocator does Whatever The Arch Needs to not leak
private data out.

Once places are converted to the allocator lets go see what is left
and ask why it is left and what API it actually needs.

I think HCH was right that nobody should be calling this in driver
code, lets aim to unexport set_memory_decrypted as an ideal goal

Jason
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help