On Mon, May 18, 2026 at 3:19 PM Barry Song <[email protected]> wrote: > > 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.
Yes, this is solvable by having a policy in allocator services where the caller is implicitly charged, while also supporting cases where the RPC includes additional explicit information about who to charge. This needs security checks to prevent arbitrary remote charges at both the ioctl() level (selinux charge_to from patch 4), and at the RPC level (not sure yet but maybe a private interface between system components and gralloc), so that only privileged components can initiate remote charges. > 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? It's currently a mix because AI model loading is largely controlled by vendor code right now. Some implementations use AHardwareBuffer_allocate, but that comes with unnecessary RPC overhead for the AI use case. So I think we should be trending towards direct allocations from dma-buf heaps because model loading time is important.
