On Tue, May 19, 2026 at 5:17 AM T.J. Mercier tjmercier@google.com wrote: [...]
Yeah I think this might work. I know of 3 cases, and it trivially solves the first two. The third requires some work on our end to extend our userspace interfaces to include the pidfd but it seems doable. I'm checking with our graphics folks.
- Direct allocation from user (e.g. app -> allocation ioctl on
/dev/dma_heap/foo) No changes required to userspace. mem_accounting=1 charges the app.
- Single hop remote allocation (e.g. app -> AHardwareBuffer_allocate
-> gralloc) gralloc has the caller's pid as described in the commit message. Open a pidfd and pass it in the dma_heap_allocation_data.
- Double hop remote allocation (e.g. app -> dequeueBuffer ->
SurfaceFlinger -> gralloc) In this case gralloc knows SurfaceFlinger's pid, but not the app's. So we need to add the app's pidfd to the SurfaceFlinger -> gralloc interface, or transfer the memcg charge from SurfaceFlinger to the app after the allocation. It'd be nice to avoid the charge transfer option entirely, but if we need it that doesn't seem so bad in this case because it's a bulk charge for the entire dmabuf rather than per-page. So the exporter doesn't need to get involved (we wouldn't need a new dma_buf_op) and we wouldn't have to worry about looping and locking for each page.
Hi T.J.,
Your description of the three different cases sounds very interesting. It helps me understand how difficult it can be to correctly charge dma-buf in the current user scenarios.
I’m wondering where I can find Android userspace code that transfers the PID of RPC callers. Do we have any existing sample code in Android for this?
Hi Barry,
In Java android.os.Binder.getCallingPid() will provide it. Here
... let me try again
Here are some examples from the framework code:
https://cs.android.com/search?q=getCallingPid%20f:ActivityManager&sq=&am...
In native code we have AIBinder_getCallingPid and android::IPCThreadState::self()->getCallingPid() (or android::hardware::IPCThreadState::self()->getCallingPid() for HIDL)
https://cs.android.com/search?q=getCallingPid%20l:cpp%20-f:prebuilt&ss=a...
Thanks very much, T.J. That is very helpful. I guess that would require user space to understand the RPC procedure, including single-hop and two-hop cases, and make the corresponding changes.
You pointed out the SurfaceFlinger cases, which are two hops. It seems that AI models are also using dma_heap, at least from what I have observed on MTK and Qualcomm phones. Likely, we need to understand those RPC relationships in userspace and make the corresponding changes. I assume AI models are a single-hop case?
Best Regards Barry