Add a new function to get and pin the iova memory in one
step (basically renaming the old msm_gem_get_iova function)
and switch msm_gem_get_iova() to only allocate an iova but
not map it in the IOMMU. This is only currently used by
msm_ioctl_gem_info() since all other users of of the iova
expect that the memory be immediately available.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Add headers for the 'gem' debugfs file to make it easier to remember
what all the values mean and move the list of virtual address regions
to the next line and add the name and map status to make it clearer
what we are looking at.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Split the operation of msm_gem_get_iova into two operations:
1) allocate an iova and 2) map (pin) the backing memory int the
iommu. This is the first step toward allowing memory pinning
to occur independently of the iova management.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The scatter gather table doesn't need to be passed in for the
MMU unmap function.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Buffer objects allocated with msm_gem_kernel_new() are mostly
freed the same way so we can save a few lines of code with a
common function.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

If any of the function calls in _msm_gem_kernel_new fail we need
to make sure to dereference the GEM object with the appropriate
function for the current locking state.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Use DRM_DEV_INFO/ERROR/WARN instead of dev_info/err/debug to generate
drm-formatted specific log messages so that it will be easy to
differentiate in case of multiple instances of driver.
Signed-off-by: NMamta Shukla <mamtashukla555@gmail.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted, vm_fault_t will become a distinct type.

Ref- commit 1c8f4220 ("mm: change return type to vm_fault_t")

Previously vm_insert_mixed() returns err which driver
mapped into VM_FAULT_* type. The new function
vmf_insert_mixed() will replace this inefficiency by
returning VM_FAULT_* type.

vmf_error() is the newly introduce inline function
in 4.17-rc6.
Signed-off-by: NSouptick Joarder <jrdr.linux@gmail.com>
Reviewed-by: NMatthew Wilcox <mawilcox@microsoft.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Commit 62e3a3e3 changed get_pages() to initialise
msm_gem_object::pages before trying to initialise msm_gem_object::sgt,
so that put_pages() would properly clean up pages in the failure
case.

However, this means that put_pages() now needs to check that
msm_gem_object::sgt is not null before trying to clean it up, and
this check was only applied to part of the cleanup code.  Move
it all into the conditional block.  (Strictly speaking we don't
need to make the kfree() conditional, but since we can't avoid
checking for null ourselves we may as well do so.)

Fixes: 62e3a3e3 ("drm/msm: fix leak in failed get_pages")
Signed-off-by: NBen Hutchings <ben.hutchings@codethink.co.uk>
Reviewed-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Commit 62e3a3e3 changed get_pages() to initialise
msm_gem_object::pages before trying to initialise msm_gem_object::sgt,
so that put_pages() would properly clean up pages in the failure
case.

However, this means that put_pages() now needs to check that
msm_gem_object::sgt is not null before trying to clean it up, and
this check was only applied to part of the cleanup code.  Move
it all into the conditional block.  (Strictly speaking we don't
need to make the kfree() conditional, but since we can't avoid
checking for null ourselves we may as well do so.)

Fixes: 62e3a3e3 ("drm/msm: fix leak in failed get_pages")
Signed-off-by: NBen Hutchings <ben.hutchings@codethink.co.uk>
Reviewed-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

This should be using drm_gem_object_put().  Also since this is done only
in driver unload path, we don't need to synchronize setting tx_gem_obj
to NULL, so juse use the _unlocked() variant.
Signed-off-by: NRob Clark <robdclark@gmail.com>

drm_gem_object_{reference,unreference,unreference_unlocked} are
deprecated functions, and merely alias to the get/put functions.
Switch to the new names.
Signed-off-by: NSteve Kowalik <steven@wedontsleep.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

get_pages doesn't keep a reference of the pages allocated
when it fails later in the code path. This can lead to
a memory leak. Keep reference of the allocated pages so
that it can be freed when msm_gem_free_object gets called
later during cleanup.
Signed-off-by: NPrakash Kamliya <pkamliya@codeaurora.org>
Signed-off-by: NSharat Masetty <smasetty@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Prep work for adding a debugfs file that dumps just submits which
trigger hangs/faults.  In this case the bo may already be in the
MADV_DONTNEED state, but will be still on the active list (since
the submit hasn't completed yet).  So the normal check that the
bo is in the WILLNEED state does not apply.  (But of course the bo
should definitely not be in the PURGED state!)
Signed-off-by: NRob Clark <robdclark@gmail.com>

We need to call reservation_object_reserve_shared() in both cases, but
this wasn't happening in the _NO_IMPLICIT submit case.

Fixes: f0a42bb5 ("drm/msm: submit support for in-fences")
Reported-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

We need to call reservation_object_reserve_shared() in both cases, but
this wasn't happening in the _NO_IMPLICIT submit case.

Fixes: f0a42bb5 ("drm/msm: submit support for in-fences")
Reported-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

In case of error, the function msm_gem_get_vaddr() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should
be replaced with IS_ERR().

Fixes: 8223286d ("drm/msm: Add a helper function for in-kernel
buffer allocations")
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Nearly all of the buffer allocations for kernel allocate an buffer object,
virtual address and GPU iova at the same time. Make a helper function to
handle the details.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
[dropped msm_fbdev conversion to new helper, since it interferes with
display-handover work, where we want to separate allocation and mapping]
Signed-off-by: NRob Clark <robdclark@gmail.com>

While I was testing the upcoming adv7533 CEC support with my Dragonboard c410
I encountered this warning several times during boot:

[    4.408309] WARNING: CPU: 3 PID: 1347 at drivers/gpu/drm/msm/msm_gem.c:312 add_vma+0x78/0x88 [msm]
[    4.412951] Modules linked in: snd_soc_hdmi_codec adv7511 cec qcom_wcnss_pil msm mdt_loader drm_kms_helper msm_rng rng_core drm
[    4.421728] CPU: 3 PID: 1347 Comm: kworker/3:3 Not tainted 4.13.0-rc1-dragonboard #111
[    4.433090] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
[    4.441081] Workqueue: events deferred_probe_work_func
[    4.447929] task: ffff800031243600 task.stack: ffff800003394000
[    4.453023] PC is at add_vma+0x78/0x88 [msm]
[    4.458823] LR is at _msm_gem_new+0xd4/0x188 [msm]
[    4.463207] pc : [<ffff000000ac01f8>] lr : [<ffff000000ac06b4>] pstate: 40000145
[    4.467811] sp : ffff8000033978a0
[    4.475357] x29: ffff8000033978a0 x28: ffff8000031dea18
[    4.478572] x27: ffff800003933a00 x26: ffff800003b39800
[    4.483953] x25: ffff8000338ff800 x24: 0000000000000001
[    4.489249] x23: 0000000000000000 x22: ffff800003b39800
[    4.494544] x21: ffff8000338ff800 x20: 0000000000000000
[    4.499839] x19: ffff800003932600 x18: 0000000000000001
[    4.505135] x17: 0000ffff8969e9e0 x16: ffff7e00000ce7a0
[    4.510429] x15: ffffffffffffffff x14: ffff8000833977ef
[    4.515724] x13: ffff8000033977f3 x12: 0000000000000038
[    4.521020] x11: 0101010101010101 x10: ffffff7f7fff7f7f
[    4.526315] x9 : 0000000000000000 x8 : ffff800003932800
[    4.531633] x7 : 0000000000000000 x6 : 000000000000003f
[    4.531644] x5 : 0000000000000040 x4 : 0000000000000000
[    4.531650] x3 : ffff800031243600 x2 : 0000000000000000
[    4.531655] x1 : 0000000000000000 x0 : 0000000000000000
[    4.531670] Call trace:
[    4.531676] Exception stack(0xffff8000033976c0 to 0xffff8000033977f0)
[    4.531683] 76c0: ffff800003932600 0001000000000000 ffff8000033978a0 ffff000000ac01f8
[    4.531688] 76e0: 0000000000000140 0000000000000000 ffff800003932550 ffff800003397780
[    4.531694] 7700: ffff800003397730 ffff000008261ce8 0000000000000000 ffff8000031d2f80
[    4.531699] 7720: ffff800003397800 ffff0000081d671c 0000000000000140 0000000000000000
[    4.531705] 7740: ffff000000ac04c0 0000000000004003 ffff800003397908 00000000014080c0
[    4.531710] 7760: 0000000000000000 ffff800003b39800 0000000000000000 0000000000000000
[    4.531716] 7780: 0000000000000000 ffff800031243600 0000000000000000 0000000000000040
[    4.531721] 77a0: 000000000000003f 0000000000000000 ffff800003932800 0000000000000000
[    4.531726] 77c0: ffffff7f7fff7f7f 0101010101010101 0000000000000038 ffff8000033977f3
[    4.531730] 77e0: ffff8000833977ef ffffffffffffffff
[    4.531881] [<ffff000000ac01f8>] add_vma+0x78/0x88 [msm]
[    4.532011] [<ffff000000ac06b4>] _msm_gem_new+0xd4/0x188 [msm]
[    4.532134] [<ffff000000ac1900>] msm_gem_new+0x10/0x18 [msm]
[    4.532260] [<ffff000000acb274>] msm_dsi_host_modeset_init+0x17c/0x268 [msm]
[    4.532384] [<ffff000000ac9024>] msm_dsi_modeset_init+0x34/0x1b8 [msm]
[    4.532504] [<ffff000000ab6168>] modeset_init+0x408/0x488 [msm]
[    4.532623] [<ffff000000ab6c4c>] mdp5_kms_init+0x2b4/0x338 [msm]
[    4.532745] [<ffff000000abeff8>] msm_drm_bind+0x218/0x4e8 [msm]
[    4.532755] [<ffff00000855d744>] try_to_bring_up_master+0x1f4/0x318
[    4.532762] [<ffff00000855d900>] component_add+0x98/0x180
[    4.532887] [<ffff000000ac8da0>] dsi_dev_probe+0x18/0x28 [msm]
[    4.532895] [<ffff000008565fe8>] platform_drv_probe+0x58/0xc0
[    4.532901] [<ffff00000856410c>] driver_probe_device+0x324/0x458
[    4.532907] [<ffff00000856440c>] __device_attach_driver+0xac/0x170
[    4.532913] [<ffff000008561ef4>] bus_for_each_drv+0x4c/0x98
[    4.532918] [<ffff000008563c38>] __device_attach+0xc0/0x160
[    4.532924] [<ffff000008564530>] device_initial_probe+0x10/0x18
[    4.532929] [<ffff000008562f84>] bus_probe_device+0x94/0xa0
[    4.532934] [<ffff0000085635d4>] deferred_probe_work_func+0x8c/0xe8
[    4.532941] [<ffff0000080d79bc>] process_one_work+0x1d4/0x330
[    4.532946] [<ffff0000080d7b60>] worker_thread+0x48/0x468
[    4.532952] [<ffff0000080ddae4>] kthread+0x12c/0x130
[    4.532958] [<ffff000008082f10>] ret_from_fork+0x10/0x40
[    4.532962] ---[ end trace b1ac6888ec40b0bb ]---
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

We recently added locking to this function but there was a direct return
that was overlooked where we need to unlock.

Fixes: 0e08270a ("drm/msm: Separate locking of buffer resources from struct_mutex")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Buffer object specific resources like pages, domains, sg list
need not be protected with struct_mutex. They can be protected
with a buffer object level lock. This simplifies locking and
makes it easier to avoid potential recursive locking scenarios
for SVM involving mmap_sem and struct_mutex. This also removes
unnecessary serialization when creating buffer objects, and also
between buffer object creation and GPU command submission.
Signed-off-by: NSushmita Susheelendra <ssusheel@codeaurora.org>
[robclark: squash in handling new locking for shrinker]
Signed-off-by: NRob Clark <robdclark@gmail.com>

It means we have to do a list traversal where we once had an index into
a table.  But the list will normally have one or two entries.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Pull some of the logic out into msm_gem_new() (since we don't need to
care about the imported-bo case), and don't defer allocating pages.  The
latter is generally a good idea, since if we are using VRAM carveout to
allocate contiguous buffers (ie. no IOMMU), the allocation is more
likely to fail.  So failing at allocation time is a more sane option.
Plus this simplifies things in the next patch.
Signed-off-by: NRob Clark <robdclark@gmail.com>

No functional change, that will come later.  But this will make it
easier to deal with dynamically created address spaces (ie. per-
process pagetables for gpu).
Signed-off-by: NRob Clark <robdclark@gmail.com>

Most, but not all, paths where calling the with struct_mutex held.  The
fast-path in msm_gem_get_iova() (plus some sub-code-paths that only run
the first time) was masking this issue.

So lets just always hold struct_mutex for hw_init().  And sprinkle some
WARN_ON()'s and might_lock() to avoid this sort of problem in the
future.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Amongst its other duties, msm_gem_new_impl adds the newly created
GEM object to the shared inactive list which may also be actively
modifiying the list during submission.  All the paths to modify
the list are protected by the mutex except for the one through
msm_gem_import which can end up causing list corruption.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
[add extra WARN_ON(!mutex_is_locked(&dev->struct_mutex))]
Signed-off-by: NRob Clark <robdclark@gmail.com>

Now that drm_[cm]alloc* helpers are simple one line wrappers around
kvmalloc_array and drm_free_large is just kvfree alias we can drop
them and replace by their native forms.

This shouldn't introduce any functional change.

Changes since v1
- fix typo in drivers/gpu//drm/etnaviv/etnaviv_gem.c - noticed by 0day
  build robot
Suggested-by: NDaniel Vetter <daniel@ffwll.ch>
Signed-off-by: Michal Hocko <mhocko@suse.com>drm: drop drm_[cm]alloc* helpers
[danvet: Fixup vgem which grew another user very recently.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NChristian König <christian.koenig@amd.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170517122312.GK18247@dhcp22.suse.cz

Zero sized buffer objects tend to make various bits of the GEM
infrastructure complain:

 WARNING: CPU: 1 PID: 2323 at drivers/gpu/drm/drm_mm.c:389 drm_mm_insert_node_generic+0x258/0x2f0
 Modules linked in:

 CPU: 1 PID: 2323 Comm: drm-api-test Tainted: G        W 4.9.0-rc4-00906-g693af44 #213
 Hardware name: Qualcomm Technologies, Inc. DB820c (DT)
 task: ffff8000d7353400 task.stack: ffff8000d7720000
 PC is at drm_mm_insert_node_generic+0x258/0x2f0
 LR is at drm_vma_offset_add+0x4c/0x70

Zero sized buffers serve no appreciable value to the user so disallow
them at create time.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Zero sized buffer objects tend to make various bits of the GEM
infrastructure complain:

 WARNING: CPU: 1 PID: 2323 at drivers/gpu/drm/drm_mm.c:389 drm_mm_insert_node_generic+0x258/0x2f0
 Modules linked in:

 CPU: 1 PID: 2323 Comm: drm-api-test Tainted: G        W 4.9.0-rc4-00906-g693af44 #213
 Hardware name: Qualcomm Technologies, Inc. DB820c (DT)
 task: ffff8000d7353400 task.stack: ffff8000d7720000
 PC is at drm_mm_insert_node_generic+0x258/0x2f0
 LR is at drm_vma_offset_add+0x4c/0x70

Zero sized buffers serve no appreciable value to the user so disallow
them at create time.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

->fault(), ->page_mkwrite(), and ->pfn_mkwrite() calls do not need to
take a vma and vmf parameter when the vma already resides in vmf.

Remove the vma parameter to simplify things.

[arnd@arndb.de: fix ARM build]
  Link: http://lkml.kernel.org/r/20170125223558.1451224-1-arnd@arndb.de
Link: http://lkml.kernel.org/r/148521301778.19116.10840599906674778980.stgit@djiang5-desk3.ch.intel.comSigned-off-by: NDave Jiang <dave.jiang@intel.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NRoss Zwisler <ross.zwisler@linux.intel.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Darrick J. Wong <darrick.wong@oracle.com>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Jan Kara <jack@suse.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The drm_mm range manager claimed to support top-down insertion, but it
was neither searching for the top-most hole that could fit the
allocation request nor fitting the request to the hole correctly.

In order to search the range efficiently, we create a secondary index
for the holes using either their size or their address. This index
allows us to find the smallest hole or the hole at the bottom or top of
the range efficiently, whilst keeping the hole stack to rapidly service
evictions.

v2: Search for holes both high and low. Rename flags to mode.
v3: Discover rb_entry_safe() and use it!
v4: Kerneldoc for enum drm_mm_insert_mode.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Christian Gmeiner <christian.gmeiner@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com> # vmwgfx
Reviewed-by: Lucas Stach <l.stach@pengutronix.de> #etnaviv
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170202210438.28702-1-chris@chris-wilson.co.uk

Since we need to change the implementation, stop exposing internals.

Provide kref_read() to read the current reference count; typically
used for debug messages.

Kills two anti-patterns:

	atomic_read(&kref->refcount)
	kref->refcount.counter
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NIngo Molnar <mingo@kernel.org>

Fixes: 9cb07b099fb ("drm/msm: support multiple address spaces")
Reported-by: NRiku Voipio <riku.voipio@linaro.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Every single user of vmf->virtual_address typed that entry to unsigned
long before doing anything with it so the type of virtual_address does
not really provide us any additional safety.  Just use masked
vmf->address which already has the appropriate type.

Link: http://lkml.kernel.org/r/1479460644-25076-3-git-send-email-jack@suse.czSigned-off-by: NJan Kara <jack@suse.cz>
Acked-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

For a5xx the gpu is 64b so we need to change iova to 64b everywhere.  On
the display side, iova is still 32b so it can ignore the upper bits.
(Although all the armv8 devices have an iommu that can map 64b pa to 32b
iova.)
Signed-off-by: NRob Clark <robdclark@gmail.com>

We can have various combinations of 64b and 32b address space, ie. 64b
CPU but 32b display and gpu, or 64b CPU and GPU but 32b display.  So
best to decouple the device iova's from mmap offset.
Signed-off-by: NRob Clark <robdclark@gmail.com>

I plan to usurp the short name of struct fence for a core kernel struct,
and so I need to rename the specialised fence/timeline for DMA
operations to make room.

A consensus was reached in
https://lists.freedesktop.org/archives/dri-devel/2016-July/113083.html
that making clear this fence applies to DMA operations was a good thing.
Since then the patch has grown a bit as usage increases, so hopefully it
remains a good thing!

(v2...: rebase, rerun spatch)
v3: Compile on msm, spotted a manual fixup that I broke.
v4: Try again for msm, sorry Daniel

coccinelle script:
@@

@@
- struct fence
+ struct dma_fence
@@

@@
- struct fence_ops
+ struct dma_fence_ops
@@

@@
- struct fence_cb
+ struct dma_fence_cb
@@

@@
- struct fence_array
+ struct dma_fence_array
@@

@@
- enum fence_flag_bits
+ enum dma_fence_flag_bits
@@

@@
(
- fence_init
+ dma_fence_init
|
- fence_release
+ dma_fence_release
|
- fence_free
+ dma_fence_free
|
- fence_get
+ dma_fence_get
|
- fence_get_rcu
+ dma_fence_get_rcu
|
- fence_put
+ dma_fence_put
|
- fence_signal
+ dma_fence_signal
|
- fence_signal_locked
+ dma_fence_signal_locked
|
- fence_default_wait
+ dma_fence_default_wait
|
- fence_add_callback
+ dma_fence_add_callback
|
- fence_remove_callback
+ dma_fence_remove_callback
|
- fence_enable_sw_signaling
+ dma_fence_enable_sw_signaling
|
- fence_is_signaled_locked
+ dma_fence_is_signaled_locked
|
- fence_is_signaled
+ dma_fence_is_signaled
|
- fence_is_later
+ dma_fence_is_later
|
- fence_later
+ dma_fence_later
|
- fence_wait_timeout
+ dma_fence_wait_timeout
|
- fence_wait_any_timeout
+ dma_fence_wait_any_timeout
|
- fence_wait
+ dma_fence_wait
|
- fence_context_alloc
+ dma_fence_context_alloc
|
- fence_array_create
+ dma_fence_array_create
|
- to_fence_array
+ to_dma_fence_array
|
- fence_is_array
+ dma_fence_is_array
|
- trace_fence_emit
+ trace_dma_fence_emit
|
- FENCE_TRACE
+ DMA_FENCE_TRACE
|
- FENCE_WARN
+ DMA_FENCE_WARN
|
- FENCE_ERR
+ DMA_FENCE_ERR
)
 (
 ...
 )
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Acked-by: NSumit Semwal <sumit.semwal@linaro.org>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161025120045.28839-1-chris@chris-wilson.co.uk

Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
need to handle such conversion in the caller. The only challenge are
those callers that wish to differentiate the error code between the
nonblocking busy check and potentially blocking wait.

v2: 9 is only 0 in German.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

An evil userspace could try to cause deadlock by passing an unfaulted-in
GEM bo as submit->bos (or submit->cmds) table.  Which will trigger
msm_gem_fault() while we already hold struct_mutex.  See:

https://github.com/freedreno/msmtest/blob/master/evilsubmittest.c

Cc: stable@vger.kernel.org
Signed-off-by: NRob Clark <robdclark@gmail.com>

The drm_gem_object_unreference() function tests whether its argument
is NULL and then returns immediately.
Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Signed-off-by: NRob Clark <robdclark@gmail.com>