Because grepping for GEM_CLOSE in Mesa GBM did not yield the results I would have expected, I wrote a small test program: https://gitlab.freedesktop.org/pq/gbm-test/blob/master/gbm-test.c

I was hypothesizing that a display-only kernel driver (with no driver at all in Mesa) doing dmabuf imports from GBM might be leaking GEM handles in Mesa. The program shows that it is not leaking, but there is another issue: the ioctl to close the handle does not seem right.

The program uses two DRM devices: one device to allocate a GBM BO with gbm_bo_create_with_modifiers() and export the buffer as dmabuf, and another display-only device to import the dmabuf and get the GEM handle. (This is a similar pattern to what a display server supporting display-only secondary DRM devices would do for zero-copy, except it would use a gbm_surface with EGL instead of gbm_bo_create.)

Doing an 'strace -e ioctl' of the test program, one allocate-export-import cycle looks like this:

ioctl(3, DRM_IOCTL_I915_GEM_CREATE, 0x7ffe128116b0) = 0
ioctl(3, DRM_IOCTL_I915_GEM_SET_TILING, 0x7ffe12811600) = 0
ioctl(3, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffe128116a4) = 0
ioctl(3, DRM_IOCTL_PRIME_HANDLE_TO_FD, 0x7ffe1281190c) = 0
ioctl(5, DRM_IOCTL_PRIME_FD_TO_HANDLE, 0x7ffe1281163c) = 0
GEM handle of imported buffer: 1
ioctl(5, DRM_IOCTL_MODE_DESTROY_DUMB, 0x7ffe12811904) = 0
ioctl(3, DRM_IOCTL_GEM_CLOSE, 0x7ffe128118a0) = 0

Is it ok to use DESTROY_DUMB here?

This is all purely by inspection, I have not hit actual problems so far.


< ickle> pq: cut-and-paste drivers/gpu/drm/drm_dumb_buffers.c drm_mode_destroy_dumb() into the report

int drm_mode_destroy_dumb(struct drm_device *dev, u32 handle,
                          struct drm_file *file_priv)
{
        if (!dev->driver->dumb_create)
                return -ENOSYS;

        if (dev->driver->dumb_destroy)
                return dev->driver->dumb_destroy(file_priv, dev, handle);
        else
                return drm_gem_dumb_destroy(file_priv, dev, handle);
}