]> git.baikalelectronics.ru Git - kernel.git/commit
drm/i915/gvt: Keep obj->dma_buf link NULL during exporting
authorTina Zhang <tina.zhang@intel.com>
Mon, 15 Jan 2018 06:41:42 +0000 (14:41 +0800)
committerRodrigo Vivi <rodrigo.vivi@intel.com>
Thu, 1 Feb 2018 15:31:58 +0000 (07:31 -0800)
commit090d309631174b6d5e56667266d93f6e3a154b52
treef5c0b1dccd0d1a977e8d74e90c7d9793a0daa5b9
parent58d20385f81ec6a2d8489384d7889ae2978d98f0
drm/i915/gvt: Keep obj->dma_buf link NULL during exporting

According to commit (9b02f521471f062c25148a03d08a29f1df1fc34f)
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Aug 15 00:02:46 2013 +0200

    drm/prime: proper locking+refcounting for obj->dma_buf link

obj->dma_buf link should be reinstated at import time.

Gvt-g dma-buf buffer exposeing might be simpler, as there won't be much
racing during Gvt-g dma-buf exposing. In other words, Gvt-g dma-buf
exposing can guarantee exposing happens before gem close ioctl, and Gvt-g
is the only exporter of the guest framebuffer.

But following the drm prime scheme can give Gvt-g a chance to increase a
dma-buf reference count during importing. Otherwise, we have to increase
the reference during exposing, which will break the case that the only
reference userspace has held was through the dma-buf fd and the reference
count is one.

Signed-off-by: Tina Zhang <tina.zhang@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Cc: Hang Yuan <hang.yuan@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
drivers/gpu/drm/i915/gvt/dmabuf.c