On Thu, Sep 10, 2026 at 12:52 PM Michal TOMA <[email protected]> wrote: > For a dma-buf from another exporter, such as udmabuf, this is an > actual import: drm_gem_prime_fd_to_handle() attaches to the dma-buf, > maps it and creates a new GEM object. The surface lookup then always > fails, because such a buffer never has a surface.
It can have one. In the same file:
PRIME_FD_TO_HANDLE(fd) -> handle H
GB_SURFACE_CREATE_EXT(buffer_handle=H) -> surface S
GB_SURFACE_REF_EXT(fd, HANDLE_PRIME) -> S
The last call works today because drm_gem_prime_fd_to_handle() returns
the cached H, and the surface is on that BO's detached_resources.
> + /*
> + * Only buffers exported by this device can have a user surface.
> + * Look the buffer up through the dma-buf, which holds a reference
> + * to it, instead of importing the fd into file_priv: the GEM handle
> + * that would create is never returned to userspace, so nothing
> + * would release it (or a foreign dma-buf) until the file is closed.
> + */
> + if (!drm_gem_is_prime_exported_dma_buf(&dev_priv->drm, dma_buf)) {
> + ret = -EINVAL;
> + goto out;
> }
This makes that last call fail. For foreign dma-bufs, could you look
for an existing import in the caller's file instead, e.g. walk
file_priv->object_idr under table_lock for an object whose
import_attach->dmabuf matches, and fail if there isn't one? A fresh
import can't have a surface, so that loses nothing and still never
creates a handle.
Also, the commit message says every call leaves a handle behind, but
the per-file PRIME cache means repeated calls with the same dma-buf
reuse one. It's fresh dma-bufs that leak. The WARN_ON removal and the
base ref fix look good.
z
smime.p7s
Description: S/MIME Cryptographic Signature
