Tue, Feb 10, 2026 at 01:29:27AM +0100, [email protected] 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 <[email protected]> wrote: >> > >> > From: Jiri Pirko <[email protected]> >> > >> > 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. [...]
