Tue, Feb 10, 2026 at 01:29:27AM +0100, jgg@ziepe.ca wrote:
On Mon, Feb 09, 2026 at 12:08:03PM -0800, John Stultz wrote:
On Mon, Feb 9, 2026 at 7:38 AM Jiri Pirko jiri@resnulli.us wrote:
From: Jiri Pirko jiri@nvidia.com
Currently the flags, which are unused, are validated for all heaps. Since the follow-up patch introduces a flag valid for only one of the heaps, allow to specify the valid flags per-heap.
I'm not really in this space anymore, so take my feedback with a grain of salt.
While the heap allocate flags argument is unused, it was intended to be used for generic allocation flags that would apply to all or at least a wide majority of heaps.
It was definitely not added to allow for per-heap or heap specific flags (as this patch tries to utilize it). That was the mess we had with ION driver that we were trying to avoid.
I don't know alot about DMA heaps..
On a CC VM system the shared/private property is universal and applies to every physical address. Not every address can dynamically change between shared and private, but every address does have a shared/private state.
By default userspace process generally run exclusively in private memory and there are very few ways for userspace to even access shared memory.
From a heaps perspective the API would be very strange, and perhaps even security dangerous, if it is returning shared memory to userspace without userspace knowing this is happening.
I'd advocate that the right design is for userspace to positively signal via this flag that it wants/accepts shared memory and without the flag shared memory should never be returned.
We can have the same behaviour with the separate heap, can't we? Userpace positively signals it wants/accepts the shared memory by choosing "system_cc_decrypted" heap name.
[...]