On Tue, Feb 10, 2026 at 10:05:14AM +0100, Jiri Pirko wrote:
Mon, Feb 09, 2026 at 09:08:03PM +0100, jstultz@google.com 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.
The intent of dma-buf heaps is to try to abstract all the different device memory constraints so there only needs to be a [usage] -> [heap] mapping, and otherwise userland can be generalized so that it doesn't need to be re-written to work with different devices/memory types. Adding heap-specific allocation flags prevents that generalization.
So instead of adding heap specific flags, the general advice has been to add a separate heap name for the flag property.
Right, my original idea was to add a separate heap. Then I spotted the flags and seemed like a great fit. Was not aware or the history or original intention. Would be probably good to document it for future generations.
So instead of flag, I will add heap named something like "system_cc_decrypted" to implement this.
It is problematic to expose a user‑visible API that depends on a name. Such a design limits our ability to extend the functionality in the future, should new use cases arise.
Thanks
Thanks!