* [PATCH v1] drm/prime: Clarify DMA-BUF/GEM Object lifetime
@ 2017-01-27 7:04 Oleksandr Andrushchenko
2017-01-27 14:00 ` Daniel Vetter
0 siblings, 1 reply; 3+ messages in thread
From: Oleksandr Andrushchenko @ 2017-01-27 7:04 UTC (permalink / raw)
To: dri-devel
Cc: oleksandr_andrushchenko, vlad.babchuk, Daniel Vetter,
andrii.anisov, olekstysh, al1img, joculator
From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
From the description of the "DMA-BUF/GEM Object references
and lifetime overview" it is not clear when exactly
dma_buf gets destroyed and memory freed: only driver
.release function mentioned which makes confusion on the
real buffer's lifetime.
Add more description so all the paths are covered.
Cc: Rob Clark <robdclark@gmail.com>
Cc: Dave Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
---
drivers/gpu/drm/drm_prime.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 8d77b2462594..893a1a6311f0 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -40,8 +40,11 @@
* On the export the dma_buf holds a reference to the exporting GEM
* object. It takes this reference in handle_to_fd_ioctl, when it
* first calls .prime_export and stores the exporting GEM object in
- * the dma_buf priv. This reference is released when the dma_buf
- * object goes away in the driver .release function.
+ * the dma_buf priv. This refernce needs to be released when the
+ * final reference to the &dma_buf itself is dropped and its
+ * &dma_buf_ops.release function is called. For GEM-based drivers,
+ * the dma_buf should be exported using drm_gem_dmabuf_export() and
+ * then released by drm_gem_dmabuf_release().
*
* On the import the importing GEM object holds a reference to the
* dma_buf (which in turn holds a ref to the exporting GEM object).
@@ -51,6 +54,15 @@
* when the imported object is destroyed, we remove the attachment
* and drop the reference to the dma_buf.
*
+ * When all the references to the dma_buf are dropped, e.g. when
+ * userspace closes both handles to the imported (fd_to_handle_ioctl)
+ * and exported (handle_to_fd_ioctl) dma_buf and closes the corresponding
+ * file descriptor (handle_to_fd), then dma_buf gets destroyed.
+ * This can also happen as a part of the clean up procedure in the
+ * driver .release function if userspace fails to properly clean up.
+ * Note that both the kernel and userspace (by keeeping the PRIME file
+ * descriptors open) can hold references onto a &dma_buf.
+ *
* Thus the chain of references always flows in one direction
* (avoiding loops): importing_gem -> dmabuf -> exporting_gem
*
--
2.7.4
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH v1] drm/prime: Clarify DMA-BUF/GEM Object lifetime
2017-01-27 7:04 [PATCH v1] drm/prime: Clarify DMA-BUF/GEM Object lifetime Oleksandr Andrushchenko
@ 2017-01-27 14:00 ` Daniel Vetter
2017-01-27 14:05 ` Oleksandr Andrushchenko
0 siblings, 1 reply; 3+ messages in thread
From: Daniel Vetter @ 2017-01-27 14:00 UTC (permalink / raw)
To: Oleksandr Andrushchenko
Cc: oleksandr_andrushchenko, vlad.babchuk, Daniel Vetter, dri-devel,
andrii.anisov, olekstysh, al1img, joculator
On Fri, Jan 27, 2017 at 09:04:25AM +0200, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>
> From the description of the "DMA-BUF/GEM Object references
> and lifetime overview" it is not clear when exactly
> dma_buf gets destroyed and memory freed: only driver
> .release function mentioned which makes confusion on the
> real buffer's lifetime.
>
> Add more description so all the paths are covered.
>
> Cc: Rob Clark <robdclark@gmail.com>
> Cc: Dave Airlie <airlied@linux.ie>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> ---
> drivers/gpu/drm/drm_prime.c | 16 ++++++++++++++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 8d77b2462594..893a1a6311f0 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -40,8 +40,11 @@
> * On the export the dma_buf holds a reference to the exporting GEM
> * object. It takes this reference in handle_to_fd_ioctl, when it
> * first calls .prime_export and stores the exporting GEM object in
> - * the dma_buf priv. This reference is released when the dma_buf
> - * object goes away in the driver .release function.
> + * the dma_buf priv. This refernce needs to be released when the
s/refernce/reference/
> + * final reference to the &dma_buf itself is dropped and its
> + * &dma_buf_ops.release function is called. For GEM-based drivers,
> + * the dma_buf should be exported using drm_gem_dmabuf_export() and
> + * then released by drm_gem_dmabuf_release().
> *
> * On the import the importing GEM object holds a reference to the
> * dma_buf (which in turn holds a ref to the exporting GEM object).
> @@ -51,6 +54,15 @@
> * when the imported object is destroyed, we remove the attachment
> * and drop the reference to the dma_buf.
> *
> + * When all the references to the dma_buf are dropped, e.g. when
> + * userspace closes both handles to the imported (fd_to_handle_ioctl)
> + * and exported (handle_to_fd_ioctl) dma_buf and closes the corresponding
Usualla we call ioctls with uppercase, e.g. HANDLE_TO_FD IOCTL.
> + * file descriptor (handle_to_fd), then dma_buf gets destroyed.
> + * This can also happen as a part of the clean up procedure in the
> + * driver .release function if userspace fails to properly clean up.
Extended the references here to full file_ops one.
Since this is all tiny, I've done this while applying, thanks a lot for
your patch.
-Daniel
> + * Note that both the kernel and userspace (by keeeping the PRIME file
> + * descriptors open) can hold references onto a &dma_buf.
> + *
> * Thus the chain of references always flows in one direction
> * (avoiding loops): importing_gem -> dmabuf -> exporting_gem
> *
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH v1] drm/prime: Clarify DMA-BUF/GEM Object lifetime
2017-01-27 14:00 ` Daniel Vetter
@ 2017-01-27 14:05 ` Oleksandr Andrushchenko
0 siblings, 0 replies; 3+ messages in thread
From: Oleksandr Andrushchenko @ 2017-01-27 14:05 UTC (permalink / raw)
To: Daniel Vetter
Cc: oleksandr_andrushchenko, vlad.babchuk, Daniel Vetter, dri-devel,
andrii.anisov, olekstysh, al1img, joculator
On 01/27/2017 04:00 PM, Daniel Vetter wrote:
> On Fri, Jan 27, 2017 at 09:04:25AM +0200, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>
>> From the description of the "DMA-BUF/GEM Object references
>> and lifetime overview" it is not clear when exactly
>> dma_buf gets destroyed and memory freed: only driver
>> .release function mentioned which makes confusion on the
>> real buffer's lifetime.
>>
>> Add more description so all the paths are covered.
>>
>> Cc: Rob Clark <robdclark@gmail.com>
>> Cc: Dave Airlie <airlied@linux.ie>
>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>> ---
>> drivers/gpu/drm/drm_prime.c | 16 ++++++++++++++--
>> 1 file changed, 14 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
>> index 8d77b2462594..893a1a6311f0 100644
>> --- a/drivers/gpu/drm/drm_prime.c
>> +++ b/drivers/gpu/drm/drm_prime.c
>> @@ -40,8 +40,11 @@
>> * On the export the dma_buf holds a reference to the exporting GEM
>> * object. It takes this reference in handle_to_fd_ioctl, when it
>> * first calls .prime_export and stores the exporting GEM object in
>> - * the dma_buf priv. This reference is released when the dma_buf
>> - * object goes away in the driver .release function.
>> + * the dma_buf priv. This refernce needs to be released when the
> s/refernce/reference/
>
>> + * final reference to the &dma_buf itself is dropped and its
>> + * &dma_buf_ops.release function is called. For GEM-based drivers,
>> + * the dma_buf should be exported using drm_gem_dmabuf_export() and
>> + * then released by drm_gem_dmabuf_release().
>> *
>> * On the import the importing GEM object holds a reference to the
>> * dma_buf (which in turn holds a ref to the exporting GEM object).
>> @@ -51,6 +54,15 @@
>> * when the imported object is destroyed, we remove the attachment
>> * and drop the reference to the dma_buf.
>> *
>> + * When all the references to the dma_buf are dropped, e.g. when
>> + * userspace closes both handles to the imported (fd_to_handle_ioctl)
>> + * and exported (handle_to_fd_ioctl) dma_buf and closes the corresponding
> Usualla we call ioctls with uppercase, e.g. HANDLE_TO_FD IOCTL.
>
>> + * file descriptor (handle_to_fd), then dma_buf gets destroyed.
>> + * This can also happen as a part of the clean up procedure in the
>> + * driver .release function if userspace fails to properly clean up.
> Extended the references here to full file_ops one.
>
> Since this is all tiny, I've done this while applying,
Thank you
> thanks a lot for
> your patch.
My pleasure
> -Daniel
>
>> + * Note that both the kernel and userspace (by keeeping the PRIME file
>> + * descriptors open) can hold references onto a &dma_buf.
>> + *
>> * Thus the chain of references always flows in one direction
>> * (avoiding loops): importing_gem -> dmabuf -> exporting_gem
>> *
>> --
>> 2.7.4
>>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-01-27 14:05 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-01-27 7:04 [PATCH v1] drm/prime: Clarify DMA-BUF/GEM Object lifetime Oleksandr Andrushchenko
2017-01-27 14:00 ` Daniel Vetter
2017-01-27 14:05 ` Oleksandr Andrushchenko
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.