Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/ttm_object.c:60: error: Cannot parse struct or union!
drivers/gpu/drm/vmwgfx/ttm_object.c:97: warning: Function parameter or member 'mem_glob' not described in 'ttm_object_device'
drivers/gpu/drm/vmwgfx/ttm_object.c:97: warning: Function parameter or member 'ops' not described in 'ttm_object_device'
drivers/gpu/drm/vmwgfx/ttm_object.c:97: warning: Function parameter or member 'dmabuf_release' not described in 'ttm_object_device'
drivers/gpu/drm/vmwgfx/ttm_object.c:97: warning: Function parameter or member 'dma_buf_size' not described in 'ttm_object_device'
drivers/gpu/drm/vmwgfx/ttm_object.c:97: warning: Function parameter or member 'idr' not described in 'ttm_object_device'
drivers/gpu/drm/vmwgfx/ttm_object.c:128: warning: Function parameter or member 'rcu_head' not described in 'ttm_ref_object'
drivers/gpu/drm/vmwgfx/ttm_object.c:128: warning: Function parameter or member 'tfile' not described in 'ttm_ref_object'
drivers/gpu/drm/vmwgfx/ttm_object.c:582: warning: Function parameter or member 'dmabuf' not described in 'get_dma_buf_unless_doomed'
drivers/gpu/drm/vmwgfx/ttm_object.c:582: warning: Excess function parameter 'dma_buf' description in 'get_dma_buf_unless_doomed'
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Roland Scheidegger <sroland@vmware.com>
Cc: Zack Rusin <zackr@vmware.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Rob Clark <rob.clark@linaro.org>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Zack Rusin <zackr@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210115181601.3432599-10-lee.jones@linaro.org
ttm_module.h deals with internals of TTM and should never
be include outside of it.
v2: also move the file around
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/404885/
User-space handles equal to zero are interpreted as uninitialized or
illegal by some drm systems (most notably kms). This means that a
dumb buffer or surface with a zero user-space handle can never be
used as a kms frame-buffer.
Cc: <stable@vger.kernel.org>
Fixes: c7eae62666 ("drm/vmwgfx: Make the object handles idr-generated")
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
Typically when we look up objects under the rcu lock, we take a reference
to make sure the returned object pointer is valid.
Now provide a function to look up an object and instead of taking a
reference to it, keep the rcu lock held when returning the object pointer.
This means that the object pointer is valid as long as the rcu lock is
held, but the object may be doomed (its refcount may be zero). Any
persistent usage of the object pointer outside of the rcu lock requires
a reference to be taken using kref_get_unless_zero().
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Instead of generating user-space object handles based on a, possibly
processed, hash of the kernel address of the object, use idr to generate
and lookup those handles. This might improve somewhat on security since
we loose all connections to the object's kernel address. Also idr is
designed to do just this.
As a todo-item, since user-space handles are now generated in sequence,
we can probably use a much simpler hash function to hash them.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
No other driver is using this functionality so move it out of TTM and
into the vmwgfx driver. Update includes and remove exports.
Also annotate to remove false static analyzer lock balance warnings.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
