On Tue, May 19, 2026 at 5:17 AM T.J. Mercier <[email protected]> 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. > > > > > > > > 1) 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. > > > > > > > > 2) 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. > > > > > > > > 3) 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=&ss=android%2Fplatform%2Fsuperproject > > 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=android%2Fplatform%2Fsuperproject
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
