<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Imported GBM BO released with DESTROY_DUMB"
href="https://bugs.freedesktop.org/show_bug.cgi?id=111316">111316</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Imported GBM BO released with DESTROY_DUMB
</td>
</tr>
<tr>
<th>Product</th>
<td>Mesa
</td>
</tr>
<tr>
<th>Version</th>
<td>18.3
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Other
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>Other
</td>
</tr>
<tr>
<th>Assignee</th>
<td>mesa-dev@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>ppaalanen@gmail.com
</td>
</tr>
<tr>
<th>QA Contact</th>
<td>mesa-dev@lists.freedesktop.org
</td>
</tr></table>
<p>
<div>
<pre>Because grepping for GEM_CLOSE in Mesa GBM did not yield the results I would
have expected, I wrote a small test program:
<a href="https://gitlab.freedesktop.org/pq/gbm-test/blob/master/gbm-test.c">https://gitlab.freedesktop.org/pq/gbm-test/blob/master/gbm-test.c</a>
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);
}</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>