[Mesa-dev] [Bug 111316] Imported GBM BO released with DESTROY_DUMB

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed Aug 7 12:33:33 UTC 2019


https://bugs.freedesktop.org/show_bug.cgi?id=111316

            Bug ID: 111316
           Summary: Imported GBM BO released with DESTROY_DUMB
           Product: Mesa
           Version: 18.3
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Other
          Assignee: mesa-dev at lists.freedesktop.org
          Reporter: ppaalanen at gmail.com
        QA Contact: mesa-dev at lists.freedesktop.org

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);
}

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20190807/d50a9d2c/attachment.html>


More information about the mesa-dev mailing list