From: Tina Zhang Date: Mon, 15 Jan 2018 06:41:42 +0000 (+0800) Subject: drm/i915/gvt: Keep obj->dma_buf link NULL during exporting X-Git-Tag: v4.19~1610^2~3^2~10 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=412718a10926f77052d8107cb3c5d9dbc96cf8c9;p=platform%2Fkernel%2Flinux-rpi.git drm/i915/gvt: Keep obj->dma_buf link NULL during exporting According to commit (319c933c71f3dbdb2b3274d1634d3494c70efa06) Author: Daniel Vetter 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 Cc: Daniel Vetter Cc: Zhenyu Wang Cc: Zhi Wang Cc: Hang Yuan Cc: Gerd Hoffmann Signed-off-by: Zhenyu Wang Signed-off-by: Rodrigo Vivi --- diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c b/drivers/gpu/drm/i915/gvt/dmabuf.c index 2ab584f..2fb7b34 100644 --- a/drivers/gpu/drm/i915/gvt/dmabuf.c +++ b/drivers/gpu/drm/i915/gvt/dmabuf.c @@ -472,7 +472,6 @@ int intel_vgpu_get_dmabuf(struct intel_vgpu *vgpu, unsigned int dmabuf_id) ret = PTR_ERR(dmabuf); goto out_free_gem; } - obj->base.dma_buf = dmabuf; i915_gem_object_put(obj);