Bug 111316 - Imported GBM BO released with DESTROY_DUMB
Summary: Imported GBM BO released with DESTROY_DUMB
Status: NEW
Alias: None
Product: Mesa
Classification: Unclassified
Component: Other (show other bugs)
Version: 18.3
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-08-07 12:33 UTC by Pekka Paalanen
Modified: 2019-08-07 12:36 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pekka Paalanen 2019-08-07 12:33:33 UTC
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);
}


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.