29 Mar, 2018
1 commit
-
commit e7cdf5c82f1773c3386b93bbcf13b9bfff29fa31 upstream.
The vk cts test:
dEQP-VK.api.external.semaphore.opaque_fd.export_multiple_times_temporarytriggers a lot of
VFS: Close: file count is 0Dave pointed out that clearing the syncobj->file from
drm_syncobj_file_release() was sufficient to silence the test, but that
opens a can of worm since we assumed that the syncobj->file was never
unset. Stop trying to reuse the same struct file for every fd pointing
to the drm_syncobj, and allocate one file for each fd instead.v2: Fixup return handling of drm_syncobj_fd_to_handle
v2.1: [airlied: fix possible syncobj ref race]
v2.2: [jekstrand: back-port to 4.14]Reported-by: Dave Airlie
Signed-off-by: Chris Wilson
Tested-by: Dave Airlie
Reviewed-by: Daniel Vetter
Signed-off-by: Dave Airlie
Signed-off-by: Jason Ekstrand
Tested-by: Clayton Craft
Signed-off-by: Greg Kroah-Hartman
29 Aug, 2017
3 commits
-
It is useful in certain circumstances to know when the fence is replaced
in a syncobj. Specifically, it may be useful to know when the fence
goes from NULL to something valid. This does make syncobj_replace_fence
a little more expensive because it has to take a lock but, in the common
case where there is no callback list, it spends a very short amount of
time inside the lock.v2:
- Don't lock in drm_syncobj_fence_get. We only really need to lock
around fence_replace to make the callback work.
v3:
- Fix the cb_list comment to make kbuild happySigned-off-by: Jason Ekstrand
Signed-off-by: Dave Airlie -
The atomic exchange operation in drm_syncobj_replace_fence is sufficient
for the case where it races with itself. However, if you have a race
between a replace_fence and dma_fence_get(syncobj->fence), you may end
up with the entire replace_fence happening between the point in time
where the one thread gets the syncobj->fence pointer and when it calls
dma_fence_get() on it. If this happens, then the reference may be
dropped before we get a chance to get a new one. The new helper uses
dma_fence_get_rcu_safe to get rid of the race.This is also needed because it allows us to do a bit more than just get
a reference in drm_syncobj_fence_get should we wish to do so.v2:
- RCU isn't that scary
- Call rcu_read_lock/unlock
- Don't rename fence to _fence
- Make the helper static inlineSigned-off-by: Jason Ekstrand
Acked-by: Christian König (v1)
Signed-off-by: Dave Airlie -
The function has far more in common with drm_syncobj_find than with
any in the get/put functions.Signed-off-by: Jason Ekstrand
Acked-by: Christian König (v1)
Signed-off-by: Dave Airlie
06 Jul, 2017
1 commit
-
the drm_file parameter is unused, so remove it.
Signed-off-by: Chris Wilson
Cc: Dave Airlie
Reviewed-by: Jason Ekstrand
Signed-off-by: Dave Airlie
14 Jun, 2017
1 commit
-
Sync objects are new toplevel drm object, that contain a
pointer to a fence. This fence can be updated via command
submission ioctls via drivers.There is also a generic wait obj API modelled on the vulkan
wait API (with code modelled on some amdgpu code).These objects can be converted to an opaque fd that can be
passes between processes.v2: rename reference/unreference to put/get (Chris)
fix leaked reference (David Zhou)
drop mutex in favour of cmpxchg (Chris)
v3: cleanups from danvet, rebase on drm_fops rename
check fd_flags is 0 in ioctls.
v4: export find/free, change replace fence to take a
syncobj. In order to support lookup first, replace
later semantics which seem in the end to be cleaner.Reviewed-by: Sean Paul
Reviewed-by: Chris Wilson
Signed-off-by: Dave Airlie
