<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/drm_syncobj.c, branch v4.14.263</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.263</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.263'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2020-10-14T07:51:09+00:00</updated>
<entry>
<title>drm/syncobj: Fix drm_syncobj_handle_to_fd refcount leak</title>
<updated>2020-10-14T07:51:09+00:00</updated>
<author>
<name>Giuliano Procida</name>
<email>gprocida@google.com</email>
</author>
<published>2020-10-14T07:51:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=328ec6286a78a71500b74255448e8f3c83d2b2c4'/>
<id>urn:sha1:328ec6286a78a71500b74255448e8f3c83d2b2c4</id>
<content type='text'>
Commit 5fb252cad61f20ae5d5a8b199f6cc4faf6f418e1, a cherry-pick of
upstream commit e7cdf5c82f1773c3386b93bbcf13b9bfff29fa31, introduced a
refcount imbalance and thus a struct drm_syncobj object leak which can
be triggered with DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD.

The function drm_syncobj_handle_to_fd first calls drm_syncobj_find
which increments the refcount of the object on success. In all of the
drm_syncobj_handle_to_fd error paths, the refcount is decremented, but
in the success path the refcount should remain at +1 as the struct
drm_syncobj now belongs to the newly opened file. Instead, the
refcount was incremented again to +2.

Fixes: 5fb252cad61f ("drm/syncobj: Stop reusing the same struct file for all syncobj -&gt; fd")
Signed-off-by: Giuliano Procida &lt;gprocida@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/syncobj: Don't leak fences when WAIT_FOR_SUBMIT is set</title>
<updated>2018-10-13T07:27:23+00:00</updated>
<author>
<name>Jason Ekstrand</name>
<email>jason@jlekstrand.net</email>
</author>
<published>2018-09-26T07:17:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=71a0556255de125b7e3fc0dc6171fb31fab2b9ad'/>
<id>urn:sha1:71a0556255de125b7e3fc0dc6171fb31fab2b9ad</id>
<content type='text'>
commit 337fe9f5c1e7de1f391c6a692531379d2aa2ee11 upstream.

We attempt to get fences earlier in the hopes that everything will
already have fences and no callbacks will be needed.  If we do succeed
in getting a fence, getting one a second time will result in a duplicate
ref with no unref.  This is causing memory leaks in Vulkan applications
that create a lot of fences; playing for a few hours can, apparently,
bring down the system.

Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107899
Reviewed-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Signed-off-by: Jason Ekstrand &lt;jason@jlekstrand.net&gt;
Signed-off-by: Sean Paul &lt;seanpaul@chromium.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180926071703.15257-1-jason.ekstrand@intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/syncobj: Stop reusing the same struct file for all syncobj -&gt; fd</title>
<updated>2018-03-28T16:24:47+00:00</updated>
<author>
<name>Chris Wilson</name>
<email>chris@chris-wilson.co.uk</email>
</author>
<published>2017-12-19T12:07:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5fb252cad61f20ae5d5a8b199f6cc4faf6f418e1'/>
<id>urn:sha1:5fb252cad61f20ae5d5a8b199f6cc4faf6f418e1</id>
<content type='text'>
commit e7cdf5c82f1773c3386b93bbcf13b9bfff29fa31 upstream.

The vk cts test:
dEQP-VK.api.external.semaphore.opaque_fd.export_multiple_times_temporary

triggers a lot of
VFS: Close: file count is 0

Dave pointed out that clearing the syncobj-&gt;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-&gt;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 &lt;airlied@redhat.com&gt;
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Tested-by: Dave Airlie &lt;airlied@redhat.com&gt;
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Jason Ekstrand &lt;jason@jlekstrand.net&gt;
Tested-by: Clayton Craft &lt;clayton.a.craft@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/syncobj: Add a signal ioctl (v3)</title>
<updated>2017-08-29T00:16:25+00:00</updated>
<author>
<name>Jason Ekstrand</name>
<email>jason@jlekstrand.net</email>
</author>
<published>2017-08-28T21:10:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ffa9443fb3d3eddf0fdf6ac473dc8b5c87f08f15'/>
<id>urn:sha1:ffa9443fb3d3eddf0fdf6ac473dc8b5c87f08f15</id>
<content type='text'>
This IOCTL provides a mechanism for userspace to trigger a sync object
directly.  There are other ways that userspace can trigger a syncobj
such as submitting a dummy batch somewhere or hanging on to a triggered
sync_file and doing an import.  This just provides an easy way to
manually trigger the sync object without weird hacks.

The motivation for this IOCTL is Vulkan fences.  Vulkan lets you create
a fence already in the signaled state so that you can wait on it
immediatly without stalling.  We could also handle this with a new
create flag to ask the driver to create a syncobj that is already
signaled but the IOCTL seemed a bit cleaner and more generic.

v2:
 - Take an array of sync objects (Dave Airlie)
v3:
 - Throw -EINVAL if pad != 0

Signed-off-by: Jason Ekstrand &lt;jason@jlekstrand.net&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm/syncobj: Add a reset ioctl (v3)</title>
<updated>2017-08-29T00:16:19+00:00</updated>
<author>
<name>Jason Ekstrand</name>
<email>jason@jlekstrand.net</email>
</author>
<published>2017-08-28T21:10:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=aa4035d2c7683d2f2fb0ffe8087abd9eabf6d54a'/>
<id>urn:sha1:aa4035d2c7683d2f2fb0ffe8087abd9eabf6d54a</id>
<content type='text'>
This just resets the dma_fence to NULL so it looks like it's never been
signaled.  This will be useful once we add the new wait API for allowing
wait on "submit and signal" behavior.

v2:
 - Take an array of sync objects (Dave Airlie)
v3:
 - Throw -EINVAL if pad != 0

Signed-off-by: Jason Ekstrand &lt;jason@jlekstrand.net&gt;
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt; (v1)
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm/syncobj: Add a syncobj_array_find helper</title>
<updated>2017-08-28T20:28:23+00:00</updated>
<author>
<name>Jason Ekstrand</name>
<email>jason@jlekstrand.net</email>
</author>
<published>2017-08-25T17:52:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3e6fb72d6cef6a46f8531a01ed290785952fe25b'/>
<id>urn:sha1:3e6fb72d6cef6a46f8531a01ed290785952fe25b</id>
<content type='text'>
The wait ioctl has a bunch of code to read an syncobj handle array from
userspace and turn it into an array of syncobj pointers.  We're about to
add two new IOCTLs which will need to work with arrays of syncobj
handles so let's make some helpers.

Signed-off-by: Jason Ekstrand &lt;jason@jlekstrand.net&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm/syncobj: Allow wait for submit and signal behavior (v5)</title>
<updated>2017-08-28T20:28:17+00:00</updated>
<author>
<name>Jason Ekstrand</name>
<email>jason@jlekstrand.net</email>
</author>
<published>2017-08-25T17:52:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e7aca5031a2fb51b6120864d0eff5478c95e6651'/>
<id>urn:sha1:e7aca5031a2fb51b6120864d0eff5478c95e6651</id>
<content type='text'>
Vulkan VkFence semantics require that the application be able to perform
a CPU wait on work which may not yet have been submitted.  This is
perfectly safe because the CPU wait has a timeout which will get
triggered eventually if no work is ever submitted.  This behavior is
advantageous for multi-threaded workloads because, so long as all of the
threads agree on what fences to use up-front, you don't have the extra
cross-thread synchronization cost of thread A telling thread B that it
has submitted its dependent work and thread B is now free to wait.

Within a single process, this can be implemented in the userspace driver
by doing exactly the same kind of tracking the app would have to do
using posix condition variables or similar.  However, in order for this
to work cross-process (as is required by VK_KHR_external_fence), we need
to handle this in the kernel.

This commit adds a WAIT_FOR_SUBMIT flag to DRM_IOCTL_SYNCOBJ_WAIT which
instructs the IOCTL to wait for the syncobj to have a non-null fence and
then wait on the fence.  Combined with DRM_IOCTL_SYNCOBJ_RESET, you can
easily get the Vulkan behavior.

v2:
 - Fix a bug in the invalid syncobj error path
 - Unify the wait-all and wait-any cases
v3:
 - Unify the timeout == 0 case a bit with the timeout &gt; 0 case
 - Use wait_event_interruptible_timeout
v4:
 - Use proxy fence
v5:
 - Revert to a combination of v2 and v3
 - Don't use proxy fences
 - Don't use wait_event_interruptible_timeout because it just adds an
   extra layer of callbacks

Signed-off-by: Jason Ekstrand &lt;jason@jlekstrand.net&gt;
Cc: Dave Airlie &lt;airlied@redhat.com&gt;
Cc: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm/syncobj: Add a CREATE_SIGNALED flag</title>
<updated>2017-08-28T20:27:41+00:00</updated>
<author>
<name>Jason Ekstrand</name>
<email>jason@jlekstrand.net</email>
</author>
<published>2017-08-25T17:52:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1fc08218ed2a42c86af5c905fe4c00885376a07e'/>
<id>urn:sha1:1fc08218ed2a42c86af5c905fe4c00885376a07e</id>
<content type='text'>
This requests that the driver create the sync object such that it
already has a signaled dma_fence attached.  Because we don't need
anything in particular (just something signaled), we use a dummy null
fence.  This is useful for Vulkan which has a similar flag that can be
passed to vkCreateFence.

Signed-off-by: Jason Ekstrand &lt;jason@jlekstrand.net&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm/syncobj: Add a callback mechanism for replace_fence (v3)</title>
<updated>2017-08-28T20:26:42+00:00</updated>
<author>
<name>Jason Ekstrand</name>
<email>jason@jlekstrand.net</email>
</author>
<published>2017-08-28T14:39:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9c19fb10a5893d6501df4d0fb93d954d5fc1d91b'/>
<id>urn:sha1:9c19fb10a5893d6501df4d0fb93d954d5fc1d91b</id>
<content type='text'>
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 happy

Signed-off-by: Jason Ekstrand &lt;jason@jlekstrand.net&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm/syncobj: add sync obj wait interface. (v8)</title>
<updated>2017-08-28T20:26:32+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2017-08-25T17:52:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5e60a10eaebab93f823295cd7ec3848ba3b6e553'/>
<id>urn:sha1:5e60a10eaebab93f823295cd7ec3848ba3b6e553</id>
<content type='text'>
This interface will allow sync object to be used to back
Vulkan fences. This API is pretty much the vulkan fence waiting
API, and I've ported the code from amdgpu.

v2: accept relative timeout, pass remaining time back
to userspace.
v3: return to absolute timeouts.
v4: absolute zero = poll,
    rewrite any/all code to have same operation for arrays
    return -EINVAL for 0 fences.
v4.1: fixup fences allocation check, use u64_to_user_ptr
v5: move to sec/nsec, and use timespec64 for calcs.
v6: use -ETIME and drop the out status flag. (-ETIME
is suggested by ickle, I can feel a shed painting)
v7: talked to Daniel/Arnd, use ktime and ns everywhere.
v8: be more careful in the timeout calculations
    use uint32_t for counter variables so we don't overflow
    graciously handle -ENOINT being returned from dma_fence_wait_timeout

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Reviewed-by: Jason Ekstrand &lt;jason@jlekstrand.net&gt;
Acked-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
</feed>
