2013-06-27 11:48:16 +00:00
|
|
|
/*
|
2014-07-01 10:57:54 +00:00
|
|
|
* Copyright (C) 2012-2014 Canonical Ltd (Maarten Lankhorst)
|
2013-06-27 11:48:16 +00:00
|
|
|
*
|
|
|
|
* Based on bo.c which bears the following copyright notice,
|
|
|
|
* but is dual licensed:
|
|
|
|
*
|
|
|
|
* Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA
|
|
|
|
* All Rights Reserved.
|
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a
|
|
|
|
* copy of this software and associated documentation files (the
|
|
|
|
* "Software"), to deal in the Software without restriction, including
|
|
|
|
* without limitation the rights to use, copy, modify, merge, publish,
|
|
|
|
* distribute, sub license, and/or sell copies of the Software, and to
|
|
|
|
* permit persons to whom the Software is furnished to do so, subject to
|
|
|
|
* the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice (including the
|
|
|
|
* next paragraph) shall be included in all copies or substantial portions
|
|
|
|
* of the Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
* THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
|
|
|
|
* DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
|
|
|
|
* OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
|
|
|
|
* USE OR OTHER DEALINGS IN THE SOFTWARE.
|
|
|
|
*
|
|
|
|
**************************************************************************/
|
|
|
|
/*
|
|
|
|
* Authors: Thomas Hellstrom <thellstrom-at-vmware-dot-com>
|
|
|
|
*/
|
|
|
|
|
2019-08-11 08:06:32 +00:00
|
|
|
#include <linux/dma-resv.h>
|
2013-06-27 11:48:16 +00:00
|
|
|
#include <linux/export.h>
|
2020-06-09 04:33:21 +00:00
|
|
|
#include <linux/mm.h>
|
dma_resv: prime lockdep annotations
Full audit of everyone:
- i915, radeon, amdgpu should be clean per their maintainers.
- vram helpers should be fine, they don't do command submission, so
really no business holding struct_mutex while doing copy_*_user. But
I haven't checked them all.
- panfrost seems to dma_resv_lock only in panfrost_job_push, which
looks clean.
- v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
copying from/to userspace happens all in v3d_lookup_bos which is
outside of the critical section.
- vmwgfx has a bunch of ioctls that do their own copy_*_user:
- vmw_execbuf_process: First this does some copies in
vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
Then comes the usual ttm reserve/validate sequence, then actual
submission/fencing, then unreserving, and finally some more
copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
details, but looks all safe.
- vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
seen, seems to only create a fence and copy it out.
- a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
found there.
Summary: vmwgfx seems to be fine too.
- virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
copying from userspace before even looking up objects through their
handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
- qxl only has qxl_execbuffer_ioctl, which calls into
qxl_process_single_command. There's a lovely comment before the
__copy_from_user_inatomic that the slowpath should be copied from
i915, but I guess that never happened. Try not to be unlucky and get
your CS data evicted between when it's written and the kernel tries
to read it. The only other copy_from_user is for relocs, but those
are done before qxl_release_reserve_list(), which seems to be the
only thing reserving buffers (in the ttm/dma_resv sense) in that
code. So looks safe.
- A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
everywhere and needs to be fixed up.
v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
dma_resv lock of a different object already. Christian mentioned that
ttm core does this too for ghost objects. intel-gfx-ci highlighted
that i915 has similar issues.
Unfortunately we can't do this in the usual module init functions,
because kernel threads don't have an ->mm - we have to wait around for
some user thread to do this.
Solution is to spawn a worker (but only once). It's horrible, but it
works.
v3: We can allocate mm! (Chris). Horrible worker hack out, clean
initcall solution in.
v4: Annotate with __init (Rob Herring)
Cc: Rob Herring <robh@kernel.org>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191104173801.2972-1-daniel.vetter@ffwll.ch
2019-11-04 17:37:59 +00:00
|
|
|
#include <linux/sched/mm.h>
|
dma-fence: prime lockdep annotations
Two in one go:
- it is allowed to call dma_fence_wait() while holding a
dma_resv_lock(). This is fundamental to how eviction works with ttm,
so required.
- it is allowed to call dma_fence_wait() from memory reclaim contexts,
specifically from shrinker callbacks (which i915 does), and from mmu
notifier callbacks (which amdgpu does, and which i915 sometimes also
does, and probably always should, but that's kinda a debate). Also
for stuff like HMM we really need to be able to do this, or things
get real dicey.
Consequence is that any critical path necessary to get to a
dma_fence_signal for a fence must never a) call dma_resv_lock nor b)
allocate memory with GFP_KERNEL. Also by implication of
dma_resv_lock(), no userspace faulting allowed. That's some supremely
obnoxious limitations, which is why we need to sprinkle the right
annotations to all relevant paths.
The one big locking context we're leaving out here is mmu notifiers,
added in
commit 23b68395c7c78a764e8963fc15a7cfd318bf187f
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Mon Aug 26 22:14:21 2019 +0200
mm/mmu_notifiers: add a lockdep map for invalidate_range_start/end
that one covers a lot of other callsites, and it's also allowed to
wait on dma-fences from mmu notifiers. But there's no ready-made
functions exposed to prime this, so I've left it out for now.
v2: Also track against mmu notifier context.
v3: kerneldoc to spec the cross-driver contract. Note that currently
i915 throws in a hard-coded 10s timeout on foreign fences (not sure
why that was done, but it's there), which is why that rule is worded
with SHOULD instead of MUST.
Also some of the mmu_notifier/shrinker rules might surprise SoC
drivers, I haven't fully audited them all. Which is infeasible anyway,
we'll need to run them with lockdep and dma-fence annotations and see
what goes boom.
v4: A spelling fix from Mika
v5: #ifdef for CONFIG_MMU_NOTIFIER. Reported by 0day. Unfortunately
this means lockdep enforcement is slightly inconsistent, it won't spot
GFP_NOIO and GFP_NOFS allocations in the wrong spot if
CONFIG_MMU_NOTIFIER is disabled in the kernel config. Oh well.
v5: Note that only drivers/gpu has a reasonable (or at least
historical) excuse to use dma_fence_wait() from shrinker and mmu
notifier callbacks. Everyone else should either have a better memory
manager model, or better hardware. This reflects discussions with
Jason Gunthorpe.
Cc: Jason Gunthorpe <jgg@mellanox.com>
Cc: Felix Kuehling <Felix.Kuehling@amd.com>
Cc: kernel test robot <lkp@intel.com>
Acked-by: Christian König <christian.koenig@amd.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@intel.com> (v4)
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Thomas Hellstrom <thomas.hellstrom@intel.com>
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
Cc: linux-rdma@vger.kernel.org
Cc: amd-gfx@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200707201229.472834-3-daniel.vetter@ffwll.ch
2020-07-07 20:12:06 +00:00
|
|
|
#include <linux/mmu_notifier.h>
|
2013-06-27 11:48:16 +00:00
|
|
|
|
2016-03-31 20:26:51 +00:00
|
|
|
/**
|
|
|
|
* DOC: Reservation Object Overview
|
|
|
|
*
|
|
|
|
* The reservation object provides a mechanism to manage shared and
|
|
|
|
* exclusive fences associated with a buffer. A reservation object
|
|
|
|
* can have attached one exclusive fence (normally associated with
|
|
|
|
* write operations) or N shared fences (read operations). The RCU
|
|
|
|
* mechanism is used to protect read access to fences from locked
|
|
|
|
* write-side updates.
|
|
|
|
*/
|
|
|
|
|
2018-06-15 08:17:38 +00:00
|
|
|
DEFINE_WD_CLASS(reservation_ww_class);
|
2013-06-27 11:48:16 +00:00
|
|
|
EXPORT_SYMBOL(reservation_ww_class);
|
2014-07-01 10:57:54 +00:00
|
|
|
|
2019-08-06 11:33:12 +00:00
|
|
|
/**
|
2019-08-11 08:06:32 +00:00
|
|
|
* dma_resv_list_alloc - allocate fence list
|
2019-08-06 11:33:12 +00:00
|
|
|
* @shared_max: number of fences we need space for
|
|
|
|
*
|
2019-08-11 08:06:32 +00:00
|
|
|
* Allocate a new dma_resv_list and make sure to correctly initialize
|
2019-08-06 11:33:12 +00:00
|
|
|
* shared_max.
|
|
|
|
*/
|
2019-08-11 08:06:32 +00:00
|
|
|
static struct dma_resv_list *dma_resv_list_alloc(unsigned int shared_max)
|
2019-08-06 11:33:12 +00:00
|
|
|
{
|
2019-08-11 08:06:32 +00:00
|
|
|
struct dma_resv_list *list;
|
2019-08-06 11:33:12 +00:00
|
|
|
|
2020-10-08 08:03:22 +00:00
|
|
|
list = kmalloc(struct_size(list, shared, shared_max), GFP_KERNEL);
|
2019-08-06 11:33:12 +00:00
|
|
|
if (!list)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
list->shared_max = (ksize(list) - offsetof(typeof(*list), shared)) /
|
|
|
|
sizeof(*list->shared);
|
|
|
|
|
|
|
|
return list;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2019-08-11 08:06:32 +00:00
|
|
|
* dma_resv_list_free - free fence list
|
2019-08-06 11:33:12 +00:00
|
|
|
* @list: list to free
|
|
|
|
*
|
2019-08-11 08:06:32 +00:00
|
|
|
* Free a dma_resv_list and make sure to drop all references.
|
2019-08-06 11:33:12 +00:00
|
|
|
*/
|
2019-08-11 08:06:32 +00:00
|
|
|
static void dma_resv_list_free(struct dma_resv_list *list)
|
2019-08-06 11:33:12 +00:00
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
if (!list)
|
|
|
|
return;
|
|
|
|
|
|
|
|
for (i = 0; i < list->shared_count; ++i)
|
|
|
|
dma_fence_put(rcu_dereference_protected(list->shared[i], true));
|
|
|
|
|
|
|
|
kfree_rcu(list, rcu);
|
|
|
|
}
|
|
|
|
|
dma_resv: prime lockdep annotations
Full audit of everyone:
- i915, radeon, amdgpu should be clean per their maintainers.
- vram helpers should be fine, they don't do command submission, so
really no business holding struct_mutex while doing copy_*_user. But
I haven't checked them all.
- panfrost seems to dma_resv_lock only in panfrost_job_push, which
looks clean.
- v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
copying from/to userspace happens all in v3d_lookup_bos which is
outside of the critical section.
- vmwgfx has a bunch of ioctls that do their own copy_*_user:
- vmw_execbuf_process: First this does some copies in
vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
Then comes the usual ttm reserve/validate sequence, then actual
submission/fencing, then unreserving, and finally some more
copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
details, but looks all safe.
- vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
seen, seems to only create a fence and copy it out.
- a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
found there.
Summary: vmwgfx seems to be fine too.
- virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
copying from userspace before even looking up objects through their
handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
- qxl only has qxl_execbuffer_ioctl, which calls into
qxl_process_single_command. There's a lovely comment before the
__copy_from_user_inatomic that the slowpath should be copied from
i915, but I guess that never happened. Try not to be unlucky and get
your CS data evicted between when it's written and the kernel tries
to read it. The only other copy_from_user is for relocs, but those
are done before qxl_release_reserve_list(), which seems to be the
only thing reserving buffers (in the ttm/dma_resv sense) in that
code. So looks safe.
- A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
everywhere and needs to be fixed up.
v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
dma_resv lock of a different object already. Christian mentioned that
ttm core does this too for ghost objects. intel-gfx-ci highlighted
that i915 has similar issues.
Unfortunately we can't do this in the usual module init functions,
because kernel threads don't have an ->mm - we have to wait around for
some user thread to do this.
Solution is to spawn a worker (but only once). It's horrible, but it
works.
v3: We can allocate mm! (Chris). Horrible worker hack out, clean
initcall solution in.
v4: Annotate with __init (Rob Herring)
Cc: Rob Herring <robh@kernel.org>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191104173801.2972-1-daniel.vetter@ffwll.ch
2019-11-04 17:37:59 +00:00
|
|
|
#if IS_ENABLED(CONFIG_LOCKDEP)
|
2019-11-11 13:11:20 +00:00
|
|
|
static int __init dma_resv_lockdep(void)
|
dma_resv: prime lockdep annotations
Full audit of everyone:
- i915, radeon, amdgpu should be clean per their maintainers.
- vram helpers should be fine, they don't do command submission, so
really no business holding struct_mutex while doing copy_*_user. But
I haven't checked them all.
- panfrost seems to dma_resv_lock only in panfrost_job_push, which
looks clean.
- v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
copying from/to userspace happens all in v3d_lookup_bos which is
outside of the critical section.
- vmwgfx has a bunch of ioctls that do their own copy_*_user:
- vmw_execbuf_process: First this does some copies in
vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
Then comes the usual ttm reserve/validate sequence, then actual
submission/fencing, then unreserving, and finally some more
copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
details, but looks all safe.
- vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
seen, seems to only create a fence and copy it out.
- a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
found there.
Summary: vmwgfx seems to be fine too.
- virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
copying from userspace before even looking up objects through their
handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
- qxl only has qxl_execbuffer_ioctl, which calls into
qxl_process_single_command. There's a lovely comment before the
__copy_from_user_inatomic that the slowpath should be copied from
i915, but I guess that never happened. Try not to be unlucky and get
your CS data evicted between when it's written and the kernel tries
to read it. The only other copy_from_user is for relocs, but those
are done before qxl_release_reserve_list(), which seems to be the
only thing reserving buffers (in the ttm/dma_resv sense) in that
code. So looks safe.
- A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
everywhere and needs to be fixed up.
v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
dma_resv lock of a different object already. Christian mentioned that
ttm core does this too for ghost objects. intel-gfx-ci highlighted
that i915 has similar issues.
Unfortunately we can't do this in the usual module init functions,
because kernel threads don't have an ->mm - we have to wait around for
some user thread to do this.
Solution is to spawn a worker (but only once). It's horrible, but it
works.
v3: We can allocate mm! (Chris). Horrible worker hack out, clean
initcall solution in.
v4: Annotate with __init (Rob Herring)
Cc: Rob Herring <robh@kernel.org>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191104173801.2972-1-daniel.vetter@ffwll.ch
2019-11-04 17:37:59 +00:00
|
|
|
{
|
|
|
|
struct mm_struct *mm = mm_alloc();
|
dma-resv: Also prime acquire ctx for lockdep
Semnatically it really doesn't matter where we grab the ticket. But
since the ticket is a fake lockdep lock, it matters for lockdep
validation purposes.
This means stuff like grabbing a ticket and then doing
copy_from/to_user isn't allowed anymore. This is a changed compared to
the current ttm fault handler, which doesn't bother with having a full
reservation. Since I'm looking into fixing the TODO entry in
ttm_mem_evict_wait_busy() I think that'll have to change sooner or
later anyway, better get started. A bit more context on why I'm
looking into this: For backwards compat with existing i915 gem code I
think we'll have to do full slowpath locking in the i915 equivalent of
the eviction code. And with dynamic dma-buf that will leak across
drivers, so another thing we need to standardize and make sure it's
done the same way everyway.
Unfortunately this means another full audit of all drivers:
- gem helpers: acquire_init is done right before taking locks, so no
problem. Same for acquire_fini and unlocking, which means nothing
that's not already covered by the dma_resv_lock rules will be caught
with this extension here to the acquire_ctx.
- etnaviv: An absolute massive amount of code is run between the
acquire_init and the first lock acquisition in submit_lock_objects.
But nothing that would touch user memory and could cause a fault.
Furthermore nothing that uses the ticket, so even if I missed
something, it would be easy to fix by pushing the acquire_init right
before the first use. Similar on the unlock/acquire_fini side.
- i915: Right now (and this will likely change a lot rsn) the acquire
ctx and actual locks are right next to each another. No problem.
- msm has a problem: submit_create calls acquire_init, but then
submit_lookup_objects() has a bunch of copy_from_user to do the
object lookups. That's the only thing before submit_lock_objects
call dma_resv_lock(). Despite all the copypasta to etnaviv, etnaviv
does not have this issue since it copies all the userspace structs
earlier. submit_cleanup does not have any such issues.
With the prep patch to pull out the acquire_ctx and reorder it msm
is going to be safe too.
- nouveau: acquire_init is right next to ttm_bo_reserve, so all good.
Similar on the acquire_fini/ttm_bo_unreserve side.
- ttm execbuf utils: acquire context and locking are even in the same
functions here (one function to reserve everything, the other to
unreserve), so all good.
- vc4: Another case where acquire context and locking are handled in
the same functions (one function to lock everything, the other to
unlock).
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Christian König <christian.koenig@amd.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
Cc: Huang Rui <ray.huang@amd.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Russell King <linux+etnaviv@armlinux.org.uk>
Cc: Christian Gmeiner <christian.gmeiner@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Sean Paul <sean@poorly.run>
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191119210844.16947-3-daniel.vetter@ffwll.ch
2019-11-19 21:08:43 +00:00
|
|
|
struct ww_acquire_ctx ctx;
|
dma_resv: prime lockdep annotations
Full audit of everyone:
- i915, radeon, amdgpu should be clean per their maintainers.
- vram helpers should be fine, they don't do command submission, so
really no business holding struct_mutex while doing copy_*_user. But
I haven't checked them all.
- panfrost seems to dma_resv_lock only in panfrost_job_push, which
looks clean.
- v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
copying from/to userspace happens all in v3d_lookup_bos which is
outside of the critical section.
- vmwgfx has a bunch of ioctls that do their own copy_*_user:
- vmw_execbuf_process: First this does some copies in
vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
Then comes the usual ttm reserve/validate sequence, then actual
submission/fencing, then unreserving, and finally some more
copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
details, but looks all safe.
- vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
seen, seems to only create a fence and copy it out.
- a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
found there.
Summary: vmwgfx seems to be fine too.
- virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
copying from userspace before even looking up objects through their
handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
- qxl only has qxl_execbuffer_ioctl, which calls into
qxl_process_single_command. There's a lovely comment before the
__copy_from_user_inatomic that the slowpath should be copied from
i915, but I guess that never happened. Try not to be unlucky and get
your CS data evicted between when it's written and the kernel tries
to read it. The only other copy_from_user is for relocs, but those
are done before qxl_release_reserve_list(), which seems to be the
only thing reserving buffers (in the ttm/dma_resv sense) in that
code. So looks safe.
- A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
everywhere and needs to be fixed up.
v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
dma_resv lock of a different object already. Christian mentioned that
ttm core does this too for ghost objects. intel-gfx-ci highlighted
that i915 has similar issues.
Unfortunately we can't do this in the usual module init functions,
because kernel threads don't have an ->mm - we have to wait around for
some user thread to do this.
Solution is to spawn a worker (but only once). It's horrible, but it
works.
v3: We can allocate mm! (Chris). Horrible worker hack out, clean
initcall solution in.
v4: Annotate with __init (Rob Herring)
Cc: Rob Herring <robh@kernel.org>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191104173801.2972-1-daniel.vetter@ffwll.ch
2019-11-04 17:37:59 +00:00
|
|
|
struct dma_resv obj;
|
2020-07-28 13:58:39 +00:00
|
|
|
struct address_space mapping;
|
dma-resv: Also prime acquire ctx for lockdep
Semnatically it really doesn't matter where we grab the ticket. But
since the ticket is a fake lockdep lock, it matters for lockdep
validation purposes.
This means stuff like grabbing a ticket and then doing
copy_from/to_user isn't allowed anymore. This is a changed compared to
the current ttm fault handler, which doesn't bother with having a full
reservation. Since I'm looking into fixing the TODO entry in
ttm_mem_evict_wait_busy() I think that'll have to change sooner or
later anyway, better get started. A bit more context on why I'm
looking into this: For backwards compat with existing i915 gem code I
think we'll have to do full slowpath locking in the i915 equivalent of
the eviction code. And with dynamic dma-buf that will leak across
drivers, so another thing we need to standardize and make sure it's
done the same way everyway.
Unfortunately this means another full audit of all drivers:
- gem helpers: acquire_init is done right before taking locks, so no
problem. Same for acquire_fini and unlocking, which means nothing
that's not already covered by the dma_resv_lock rules will be caught
with this extension here to the acquire_ctx.
- etnaviv: An absolute massive amount of code is run between the
acquire_init and the first lock acquisition in submit_lock_objects.
But nothing that would touch user memory and could cause a fault.
Furthermore nothing that uses the ticket, so even if I missed
something, it would be easy to fix by pushing the acquire_init right
before the first use. Similar on the unlock/acquire_fini side.
- i915: Right now (and this will likely change a lot rsn) the acquire
ctx and actual locks are right next to each another. No problem.
- msm has a problem: submit_create calls acquire_init, but then
submit_lookup_objects() has a bunch of copy_from_user to do the
object lookups. That's the only thing before submit_lock_objects
call dma_resv_lock(). Despite all the copypasta to etnaviv, etnaviv
does not have this issue since it copies all the userspace structs
earlier. submit_cleanup does not have any such issues.
With the prep patch to pull out the acquire_ctx and reorder it msm
is going to be safe too.
- nouveau: acquire_init is right next to ttm_bo_reserve, so all good.
Similar on the acquire_fini/ttm_bo_unreserve side.
- ttm execbuf utils: acquire context and locking are even in the same
functions here (one function to reserve everything, the other to
unreserve), so all good.
- vc4: Another case where acquire context and locking are handled in
the same functions (one function to lock everything, the other to
unlock).
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Christian König <christian.koenig@amd.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
Cc: Huang Rui <ray.huang@amd.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Russell King <linux+etnaviv@armlinux.org.uk>
Cc: Christian Gmeiner <christian.gmeiner@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Sean Paul <sean@poorly.run>
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191119210844.16947-3-daniel.vetter@ffwll.ch
2019-11-19 21:08:43 +00:00
|
|
|
int ret;
|
dma_resv: prime lockdep annotations
Full audit of everyone:
- i915, radeon, amdgpu should be clean per their maintainers.
- vram helpers should be fine, they don't do command submission, so
really no business holding struct_mutex while doing copy_*_user. But
I haven't checked them all.
- panfrost seems to dma_resv_lock only in panfrost_job_push, which
looks clean.
- v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
copying from/to userspace happens all in v3d_lookup_bos which is
outside of the critical section.
- vmwgfx has a bunch of ioctls that do their own copy_*_user:
- vmw_execbuf_process: First this does some copies in
vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
Then comes the usual ttm reserve/validate sequence, then actual
submission/fencing, then unreserving, and finally some more
copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
details, but looks all safe.
- vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
seen, seems to only create a fence and copy it out.
- a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
found there.
Summary: vmwgfx seems to be fine too.
- virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
copying from userspace before even looking up objects through their
handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
- qxl only has qxl_execbuffer_ioctl, which calls into
qxl_process_single_command. There's a lovely comment before the
__copy_from_user_inatomic that the slowpath should be copied from
i915, but I guess that never happened. Try not to be unlucky and get
your CS data evicted between when it's written and the kernel tries
to read it. The only other copy_from_user is for relocs, but those
are done before qxl_release_reserve_list(), which seems to be the
only thing reserving buffers (in the ttm/dma_resv sense) in that
code. So looks safe.
- A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
everywhere and needs to be fixed up.
v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
dma_resv lock of a different object already. Christian mentioned that
ttm core does this too for ghost objects. intel-gfx-ci highlighted
that i915 has similar issues.
Unfortunately we can't do this in the usual module init functions,
because kernel threads don't have an ->mm - we have to wait around for
some user thread to do this.
Solution is to spawn a worker (but only once). It's horrible, but it
works.
v3: We can allocate mm! (Chris). Horrible worker hack out, clean
initcall solution in.
v4: Annotate with __init (Rob Herring)
Cc: Rob Herring <robh@kernel.org>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191104173801.2972-1-daniel.vetter@ffwll.ch
2019-11-04 17:37:59 +00:00
|
|
|
|
|
|
|
if (!mm)
|
2019-11-11 13:11:20 +00:00
|
|
|
return -ENOMEM;
|
dma_resv: prime lockdep annotations
Full audit of everyone:
- i915, radeon, amdgpu should be clean per their maintainers.
- vram helpers should be fine, they don't do command submission, so
really no business holding struct_mutex while doing copy_*_user. But
I haven't checked them all.
- panfrost seems to dma_resv_lock only in panfrost_job_push, which
looks clean.
- v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
copying from/to userspace happens all in v3d_lookup_bos which is
outside of the critical section.
- vmwgfx has a bunch of ioctls that do their own copy_*_user:
- vmw_execbuf_process: First this does some copies in
vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
Then comes the usual ttm reserve/validate sequence, then actual
submission/fencing, then unreserving, and finally some more
copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
details, but looks all safe.
- vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
seen, seems to only create a fence and copy it out.
- a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
found there.
Summary: vmwgfx seems to be fine too.
- virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
copying from userspace before even looking up objects through their
handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
- qxl only has qxl_execbuffer_ioctl, which calls into
qxl_process_single_command. There's a lovely comment before the
__copy_from_user_inatomic that the slowpath should be copied from
i915, but I guess that never happened. Try not to be unlucky and get
your CS data evicted between when it's written and the kernel tries
to read it. The only other copy_from_user is for relocs, but those
are done before qxl_release_reserve_list(), which seems to be the
only thing reserving buffers (in the ttm/dma_resv sense) in that
code. So looks safe.
- A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
everywhere and needs to be fixed up.
v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
dma_resv lock of a different object already. Christian mentioned that
ttm core does this too for ghost objects. intel-gfx-ci highlighted
that i915 has similar issues.
Unfortunately we can't do this in the usual module init functions,
because kernel threads don't have an ->mm - we have to wait around for
some user thread to do this.
Solution is to spawn a worker (but only once). It's horrible, but it
works.
v3: We can allocate mm! (Chris). Horrible worker hack out, clean
initcall solution in.
v4: Annotate with __init (Rob Herring)
Cc: Rob Herring <robh@kernel.org>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191104173801.2972-1-daniel.vetter@ffwll.ch
2019-11-04 17:37:59 +00:00
|
|
|
|
|
|
|
dma_resv_init(&obj);
|
2020-07-28 13:58:39 +00:00
|
|
|
address_space_init_once(&mapping);
|
dma_resv: prime lockdep annotations
Full audit of everyone:
- i915, radeon, amdgpu should be clean per their maintainers.
- vram helpers should be fine, they don't do command submission, so
really no business holding struct_mutex while doing copy_*_user. But
I haven't checked them all.
- panfrost seems to dma_resv_lock only in panfrost_job_push, which
looks clean.
- v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
copying from/to userspace happens all in v3d_lookup_bos which is
outside of the critical section.
- vmwgfx has a bunch of ioctls that do their own copy_*_user:
- vmw_execbuf_process: First this does some copies in
vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
Then comes the usual ttm reserve/validate sequence, then actual
submission/fencing, then unreserving, and finally some more
copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
details, but looks all safe.
- vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
seen, seems to only create a fence and copy it out.
- a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
found there.
Summary: vmwgfx seems to be fine too.
- virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
copying from userspace before even looking up objects through their
handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
- qxl only has qxl_execbuffer_ioctl, which calls into
qxl_process_single_command. There's a lovely comment before the
__copy_from_user_inatomic that the slowpath should be copied from
i915, but I guess that never happened. Try not to be unlucky and get
your CS data evicted between when it's written and the kernel tries
to read it. The only other copy_from_user is for relocs, but those
are done before qxl_release_reserve_list(), which seems to be the
only thing reserving buffers (in the ttm/dma_resv sense) in that
code. So looks safe.
- A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
everywhere and needs to be fixed up.
v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
dma_resv lock of a different object already. Christian mentioned that
ttm core does this too for ghost objects. intel-gfx-ci highlighted
that i915 has similar issues.
Unfortunately we can't do this in the usual module init functions,
because kernel threads don't have an ->mm - we have to wait around for
some user thread to do this.
Solution is to spawn a worker (but only once). It's horrible, but it
works.
v3: We can allocate mm! (Chris). Horrible worker hack out, clean
initcall solution in.
v4: Annotate with __init (Rob Herring)
Cc: Rob Herring <robh@kernel.org>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191104173801.2972-1-daniel.vetter@ffwll.ch
2019-11-04 17:37:59 +00:00
|
|
|
|
2020-06-09 04:33:21 +00:00
|
|
|
mmap_read_lock(mm);
|
dma-resv: Also prime acquire ctx for lockdep
Semnatically it really doesn't matter where we grab the ticket. But
since the ticket is a fake lockdep lock, it matters for lockdep
validation purposes.
This means stuff like grabbing a ticket and then doing
copy_from/to_user isn't allowed anymore. This is a changed compared to
the current ttm fault handler, which doesn't bother with having a full
reservation. Since I'm looking into fixing the TODO entry in
ttm_mem_evict_wait_busy() I think that'll have to change sooner or
later anyway, better get started. A bit more context on why I'm
looking into this: For backwards compat with existing i915 gem code I
think we'll have to do full slowpath locking in the i915 equivalent of
the eviction code. And with dynamic dma-buf that will leak across
drivers, so another thing we need to standardize and make sure it's
done the same way everyway.
Unfortunately this means another full audit of all drivers:
- gem helpers: acquire_init is done right before taking locks, so no
problem. Same for acquire_fini and unlocking, which means nothing
that's not already covered by the dma_resv_lock rules will be caught
with this extension here to the acquire_ctx.
- etnaviv: An absolute massive amount of code is run between the
acquire_init and the first lock acquisition in submit_lock_objects.
But nothing that would touch user memory and could cause a fault.
Furthermore nothing that uses the ticket, so even if I missed
something, it would be easy to fix by pushing the acquire_init right
before the first use. Similar on the unlock/acquire_fini side.
- i915: Right now (and this will likely change a lot rsn) the acquire
ctx and actual locks are right next to each another. No problem.
- msm has a problem: submit_create calls acquire_init, but then
submit_lookup_objects() has a bunch of copy_from_user to do the
object lookups. That's the only thing before submit_lock_objects
call dma_resv_lock(). Despite all the copypasta to etnaviv, etnaviv
does not have this issue since it copies all the userspace structs
earlier. submit_cleanup does not have any such issues.
With the prep patch to pull out the acquire_ctx and reorder it msm
is going to be safe too.
- nouveau: acquire_init is right next to ttm_bo_reserve, so all good.
Similar on the acquire_fini/ttm_bo_unreserve side.
- ttm execbuf utils: acquire context and locking are even in the same
functions here (one function to reserve everything, the other to
unreserve), so all good.
- vc4: Another case where acquire context and locking are handled in
the same functions (one function to lock everything, the other to
unlock).
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Christian König <christian.koenig@amd.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
Cc: Huang Rui <ray.huang@amd.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Russell King <linux+etnaviv@armlinux.org.uk>
Cc: Christian Gmeiner <christian.gmeiner@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Sean Paul <sean@poorly.run>
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191119210844.16947-3-daniel.vetter@ffwll.ch
2019-11-19 21:08:43 +00:00
|
|
|
ww_acquire_init(&ctx, &reservation_ww_class);
|
|
|
|
ret = dma_resv_lock(&obj, &ctx);
|
|
|
|
if (ret == -EDEADLK)
|
|
|
|
dma_resv_lock_slow(&obj, &ctx);
|
dma_resv: prime lockdep annotations
Full audit of everyone:
- i915, radeon, amdgpu should be clean per their maintainers.
- vram helpers should be fine, they don't do command submission, so
really no business holding struct_mutex while doing copy_*_user. But
I haven't checked them all.
- panfrost seems to dma_resv_lock only in panfrost_job_push, which
looks clean.
- v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
copying from/to userspace happens all in v3d_lookup_bos which is
outside of the critical section.
- vmwgfx has a bunch of ioctls that do their own copy_*_user:
- vmw_execbuf_process: First this does some copies in
vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
Then comes the usual ttm reserve/validate sequence, then actual
submission/fencing, then unreserving, and finally some more
copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
details, but looks all safe.
- vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
seen, seems to only create a fence and copy it out.
- a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
found there.
Summary: vmwgfx seems to be fine too.
- virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
copying from userspace before even looking up objects through their
handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
- qxl only has qxl_execbuffer_ioctl, which calls into
qxl_process_single_command. There's a lovely comment before the
__copy_from_user_inatomic that the slowpath should be copied from
i915, but I guess that never happened. Try not to be unlucky and get
your CS data evicted between when it's written and the kernel tries
to read it. The only other copy_from_user is for relocs, but those
are done before qxl_release_reserve_list(), which seems to be the
only thing reserving buffers (in the ttm/dma_resv sense) in that
code. So looks safe.
- A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
everywhere and needs to be fixed up.
v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
dma_resv lock of a different object already. Christian mentioned that
ttm core does this too for ghost objects. intel-gfx-ci highlighted
that i915 has similar issues.
Unfortunately we can't do this in the usual module init functions,
because kernel threads don't have an ->mm - we have to wait around for
some user thread to do this.
Solution is to spawn a worker (but only once). It's horrible, but it
works.
v3: We can allocate mm! (Chris). Horrible worker hack out, clean
initcall solution in.
v4: Annotate with __init (Rob Herring)
Cc: Rob Herring <robh@kernel.org>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191104173801.2972-1-daniel.vetter@ffwll.ch
2019-11-04 17:37:59 +00:00
|
|
|
fs_reclaim_acquire(GFP_KERNEL);
|
2020-07-28 13:58:39 +00:00
|
|
|
/* for unmap_mapping_range on trylocked buffer objects in shrinkers */
|
|
|
|
i_mmap_lock_write(&mapping);
|
|
|
|
i_mmap_unlock_write(&mapping);
|
dma-fence: prime lockdep annotations
Two in one go:
- it is allowed to call dma_fence_wait() while holding a
dma_resv_lock(). This is fundamental to how eviction works with ttm,
so required.
- it is allowed to call dma_fence_wait() from memory reclaim contexts,
specifically from shrinker callbacks (which i915 does), and from mmu
notifier callbacks (which amdgpu does, and which i915 sometimes also
does, and probably always should, but that's kinda a debate). Also
for stuff like HMM we really need to be able to do this, or things
get real dicey.
Consequence is that any critical path necessary to get to a
dma_fence_signal for a fence must never a) call dma_resv_lock nor b)
allocate memory with GFP_KERNEL. Also by implication of
dma_resv_lock(), no userspace faulting allowed. That's some supremely
obnoxious limitations, which is why we need to sprinkle the right
annotations to all relevant paths.
The one big locking context we're leaving out here is mmu notifiers,
added in
commit 23b68395c7c78a764e8963fc15a7cfd318bf187f
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Mon Aug 26 22:14:21 2019 +0200
mm/mmu_notifiers: add a lockdep map for invalidate_range_start/end
that one covers a lot of other callsites, and it's also allowed to
wait on dma-fences from mmu notifiers. But there's no ready-made
functions exposed to prime this, so I've left it out for now.
v2: Also track against mmu notifier context.
v3: kerneldoc to spec the cross-driver contract. Note that currently
i915 throws in a hard-coded 10s timeout on foreign fences (not sure
why that was done, but it's there), which is why that rule is worded
with SHOULD instead of MUST.
Also some of the mmu_notifier/shrinker rules might surprise SoC
drivers, I haven't fully audited them all. Which is infeasible anyway,
we'll need to run them with lockdep and dma-fence annotations and see
what goes boom.
v4: A spelling fix from Mika
v5: #ifdef for CONFIG_MMU_NOTIFIER. Reported by 0day. Unfortunately
this means lockdep enforcement is slightly inconsistent, it won't spot
GFP_NOIO and GFP_NOFS allocations in the wrong spot if
CONFIG_MMU_NOTIFIER is disabled in the kernel config. Oh well.
v5: Note that only drivers/gpu has a reasonable (or at least
historical) excuse to use dma_fence_wait() from shrinker and mmu
notifier callbacks. Everyone else should either have a better memory
manager model, or better hardware. This reflects discussions with
Jason Gunthorpe.
Cc: Jason Gunthorpe <jgg@mellanox.com>
Cc: Felix Kuehling <Felix.Kuehling@amd.com>
Cc: kernel test robot <lkp@intel.com>
Acked-by: Christian König <christian.koenig@amd.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@intel.com> (v4)
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Thomas Hellstrom <thomas.hellstrom@intel.com>
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
Cc: linux-rdma@vger.kernel.org
Cc: amd-gfx@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200707201229.472834-3-daniel.vetter@ffwll.ch
2020-07-07 20:12:06 +00:00
|
|
|
#ifdef CONFIG_MMU_NOTIFIER
|
|
|
|
lock_map_acquire(&__mmu_notifier_invalidate_range_start_map);
|
|
|
|
__dma_fence_might_wait();
|
|
|
|
lock_map_release(&__mmu_notifier_invalidate_range_start_map);
|
|
|
|
#else
|
|
|
|
__dma_fence_might_wait();
|
|
|
|
#endif
|
dma_resv: prime lockdep annotations
Full audit of everyone:
- i915, radeon, amdgpu should be clean per their maintainers.
- vram helpers should be fine, they don't do command submission, so
really no business holding struct_mutex while doing copy_*_user. But
I haven't checked them all.
- panfrost seems to dma_resv_lock only in panfrost_job_push, which
looks clean.
- v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
copying from/to userspace happens all in v3d_lookup_bos which is
outside of the critical section.
- vmwgfx has a bunch of ioctls that do their own copy_*_user:
- vmw_execbuf_process: First this does some copies in
vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
Then comes the usual ttm reserve/validate sequence, then actual
submission/fencing, then unreserving, and finally some more
copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
details, but looks all safe.
- vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
seen, seems to only create a fence and copy it out.
- a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
found there.
Summary: vmwgfx seems to be fine too.
- virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
copying from userspace before even looking up objects through their
handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
- qxl only has qxl_execbuffer_ioctl, which calls into
qxl_process_single_command. There's a lovely comment before the
__copy_from_user_inatomic that the slowpath should be copied from
i915, but I guess that never happened. Try not to be unlucky and get
your CS data evicted between when it's written and the kernel tries
to read it. The only other copy_from_user is for relocs, but those
are done before qxl_release_reserve_list(), which seems to be the
only thing reserving buffers (in the ttm/dma_resv sense) in that
code. So looks safe.
- A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
everywhere and needs to be fixed up.
v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
dma_resv lock of a different object already. Christian mentioned that
ttm core does this too for ghost objects. intel-gfx-ci highlighted
that i915 has similar issues.
Unfortunately we can't do this in the usual module init functions,
because kernel threads don't have an ->mm - we have to wait around for
some user thread to do this.
Solution is to spawn a worker (but only once). It's horrible, but it
works.
v3: We can allocate mm! (Chris). Horrible worker hack out, clean
initcall solution in.
v4: Annotate with __init (Rob Herring)
Cc: Rob Herring <robh@kernel.org>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191104173801.2972-1-daniel.vetter@ffwll.ch
2019-11-04 17:37:59 +00:00
|
|
|
fs_reclaim_release(GFP_KERNEL);
|
|
|
|
ww_mutex_unlock(&obj.lock);
|
dma-resv: Also prime acquire ctx for lockdep
Semnatically it really doesn't matter where we grab the ticket. But
since the ticket is a fake lockdep lock, it matters for lockdep
validation purposes.
This means stuff like grabbing a ticket and then doing
copy_from/to_user isn't allowed anymore. This is a changed compared to
the current ttm fault handler, which doesn't bother with having a full
reservation. Since I'm looking into fixing the TODO entry in
ttm_mem_evict_wait_busy() I think that'll have to change sooner or
later anyway, better get started. A bit more context on why I'm
looking into this: For backwards compat with existing i915 gem code I
think we'll have to do full slowpath locking in the i915 equivalent of
the eviction code. And with dynamic dma-buf that will leak across
drivers, so another thing we need to standardize and make sure it's
done the same way everyway.
Unfortunately this means another full audit of all drivers:
- gem helpers: acquire_init is done right before taking locks, so no
problem. Same for acquire_fini and unlocking, which means nothing
that's not already covered by the dma_resv_lock rules will be caught
with this extension here to the acquire_ctx.
- etnaviv: An absolute massive amount of code is run between the
acquire_init and the first lock acquisition in submit_lock_objects.
But nothing that would touch user memory and could cause a fault.
Furthermore nothing that uses the ticket, so even if I missed
something, it would be easy to fix by pushing the acquire_init right
before the first use. Similar on the unlock/acquire_fini side.
- i915: Right now (and this will likely change a lot rsn) the acquire
ctx and actual locks are right next to each another. No problem.
- msm has a problem: submit_create calls acquire_init, but then
submit_lookup_objects() has a bunch of copy_from_user to do the
object lookups. That's the only thing before submit_lock_objects
call dma_resv_lock(). Despite all the copypasta to etnaviv, etnaviv
does not have this issue since it copies all the userspace structs
earlier. submit_cleanup does not have any such issues.
With the prep patch to pull out the acquire_ctx and reorder it msm
is going to be safe too.
- nouveau: acquire_init is right next to ttm_bo_reserve, so all good.
Similar on the acquire_fini/ttm_bo_unreserve side.
- ttm execbuf utils: acquire context and locking are even in the same
functions here (one function to reserve everything, the other to
unreserve), so all good.
- vc4: Another case where acquire context and locking are handled in
the same functions (one function to lock everything, the other to
unlock).
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Christian König <christian.koenig@amd.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
Cc: Huang Rui <ray.huang@amd.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Russell King <linux+etnaviv@armlinux.org.uk>
Cc: Christian Gmeiner <christian.gmeiner@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Sean Paul <sean@poorly.run>
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191119210844.16947-3-daniel.vetter@ffwll.ch
2019-11-19 21:08:43 +00:00
|
|
|
ww_acquire_fini(&ctx);
|
2020-06-09 04:33:21 +00:00
|
|
|
mmap_read_unlock(mm);
|
dma_resv: prime lockdep annotations
Full audit of everyone:
- i915, radeon, amdgpu should be clean per their maintainers.
- vram helpers should be fine, they don't do command submission, so
really no business holding struct_mutex while doing copy_*_user. But
I haven't checked them all.
- panfrost seems to dma_resv_lock only in panfrost_job_push, which
looks clean.
- v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
copying from/to userspace happens all in v3d_lookup_bos which is
outside of the critical section.
- vmwgfx has a bunch of ioctls that do their own copy_*_user:
- vmw_execbuf_process: First this does some copies in
vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
Then comes the usual ttm reserve/validate sequence, then actual
submission/fencing, then unreserving, and finally some more
copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
details, but looks all safe.
- vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
seen, seems to only create a fence and copy it out.
- a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
found there.
Summary: vmwgfx seems to be fine too.
- virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
copying from userspace before even looking up objects through their
handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
- qxl only has qxl_execbuffer_ioctl, which calls into
qxl_process_single_command. There's a lovely comment before the
__copy_from_user_inatomic that the slowpath should be copied from
i915, but I guess that never happened. Try not to be unlucky and get
your CS data evicted between when it's written and the kernel tries
to read it. The only other copy_from_user is for relocs, but those
are done before qxl_release_reserve_list(), which seems to be the
only thing reserving buffers (in the ttm/dma_resv sense) in that
code. So looks safe.
- A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
everywhere and needs to be fixed up.
v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
dma_resv lock of a different object already. Christian mentioned that
ttm core does this too for ghost objects. intel-gfx-ci highlighted
that i915 has similar issues.
Unfortunately we can't do this in the usual module init functions,
because kernel threads don't have an ->mm - we have to wait around for
some user thread to do this.
Solution is to spawn a worker (but only once). It's horrible, but it
works.
v3: We can allocate mm! (Chris). Horrible worker hack out, clean
initcall solution in.
v4: Annotate with __init (Rob Herring)
Cc: Rob Herring <robh@kernel.org>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191104173801.2972-1-daniel.vetter@ffwll.ch
2019-11-04 17:37:59 +00:00
|
|
|
|
|
|
|
mmput(mm);
|
2019-11-11 13:11:20 +00:00
|
|
|
|
|
|
|
return 0;
|
dma_resv: prime lockdep annotations
Full audit of everyone:
- i915, radeon, amdgpu should be clean per their maintainers.
- vram helpers should be fine, they don't do command submission, so
really no business holding struct_mutex while doing copy_*_user. But
I haven't checked them all.
- panfrost seems to dma_resv_lock only in panfrost_job_push, which
looks clean.
- v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
copying from/to userspace happens all in v3d_lookup_bos which is
outside of the critical section.
- vmwgfx has a bunch of ioctls that do their own copy_*_user:
- vmw_execbuf_process: First this does some copies in
vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
Then comes the usual ttm reserve/validate sequence, then actual
submission/fencing, then unreserving, and finally some more
copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
details, but looks all safe.
- vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
seen, seems to only create a fence and copy it out.
- a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
found there.
Summary: vmwgfx seems to be fine too.
- virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
copying from userspace before even looking up objects through their
handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
- qxl only has qxl_execbuffer_ioctl, which calls into
qxl_process_single_command. There's a lovely comment before the
__copy_from_user_inatomic that the slowpath should be copied from
i915, but I guess that never happened. Try not to be unlucky and get
your CS data evicted between when it's written and the kernel tries
to read it. The only other copy_from_user is for relocs, but those
are done before qxl_release_reserve_list(), which seems to be the
only thing reserving buffers (in the ttm/dma_resv sense) in that
code. So looks safe.
- A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
everywhere and needs to be fixed up.
v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
dma_resv lock of a different object already. Christian mentioned that
ttm core does this too for ghost objects. intel-gfx-ci highlighted
that i915 has similar issues.
Unfortunately we can't do this in the usual module init functions,
because kernel threads don't have an ->mm - we have to wait around for
some user thread to do this.
Solution is to spawn a worker (but only once). It's horrible, but it
works.
v3: We can allocate mm! (Chris). Horrible worker hack out, clean
initcall solution in.
v4: Annotate with __init (Rob Herring)
Cc: Rob Herring <robh@kernel.org>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191104173801.2972-1-daniel.vetter@ffwll.ch
2019-11-04 17:37:59 +00:00
|
|
|
}
|
|
|
|
subsys_initcall(dma_resv_lockdep);
|
|
|
|
#endif
|
|
|
|
|
2019-06-26 14:31:46 +00:00
|
|
|
/**
|
2019-08-11 08:06:32 +00:00
|
|
|
* dma_resv_init - initialize a reservation object
|
2019-06-26 14:31:46 +00:00
|
|
|
* @obj: the reservation object
|
|
|
|
*/
|
2019-08-11 08:06:32 +00:00
|
|
|
void dma_resv_init(struct dma_resv *obj)
|
2019-06-26 14:31:46 +00:00
|
|
|
{
|
|
|
|
ww_mutex_init(&obj->lock, &reservation_ww_class);
|
2020-07-20 15:55:18 +00:00
|
|
|
seqcount_ww_mutex_init(&obj->seq, &obj->lock);
|
2019-08-14 18:24:01 +00:00
|
|
|
|
2019-06-26 14:31:46 +00:00
|
|
|
RCU_INIT_POINTER(obj->fence, NULL);
|
|
|
|
RCU_INIT_POINTER(obj->fence_excl, NULL);
|
|
|
|
}
|
2019-08-11 08:06:32 +00:00
|
|
|
EXPORT_SYMBOL(dma_resv_init);
|
2019-06-26 14:31:46 +00:00
|
|
|
|
|
|
|
/**
|
2019-08-11 08:06:32 +00:00
|
|
|
* dma_resv_fini - destroys a reservation object
|
2019-06-26 14:31:46 +00:00
|
|
|
* @obj: the reservation object
|
|
|
|
*/
|
2019-08-11 08:06:32 +00:00
|
|
|
void dma_resv_fini(struct dma_resv *obj)
|
2019-06-26 14:31:46 +00:00
|
|
|
{
|
2019-08-11 08:06:32 +00:00
|
|
|
struct dma_resv_list *fobj;
|
2019-06-26 14:31:46 +00:00
|
|
|
struct dma_fence *excl;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This object should be dead and all references must have
|
|
|
|
* been released to it, so no need to be protected with rcu.
|
|
|
|
*/
|
|
|
|
excl = rcu_dereference_protected(obj->fence_excl, 1);
|
|
|
|
if (excl)
|
|
|
|
dma_fence_put(excl);
|
|
|
|
|
|
|
|
fobj = rcu_dereference_protected(obj->fence, 1);
|
2019-08-11 08:06:32 +00:00
|
|
|
dma_resv_list_free(fobj);
|
2019-06-26 14:31:46 +00:00
|
|
|
ww_mutex_destroy(&obj->lock);
|
|
|
|
}
|
2019-08-11 08:06:32 +00:00
|
|
|
EXPORT_SYMBOL(dma_resv_fini);
|
2019-06-26 14:31:46 +00:00
|
|
|
|
2016-03-31 20:26:51 +00:00
|
|
|
/**
|
2019-08-11 08:06:32 +00:00
|
|
|
* dma_resv_reserve_shared - Reserve space to add shared fences to
|
|
|
|
* a dma_resv.
|
2016-03-31 20:26:51 +00:00
|
|
|
* @obj: reservation object
|
2018-09-19 14:12:25 +00:00
|
|
|
* @num_fences: number of fences we want to add
|
2016-03-31 20:26:51 +00:00
|
|
|
*
|
2019-08-11 08:06:32 +00:00
|
|
|
* Should be called before dma_resv_add_shared_fence(). Must
|
2016-03-31 20:26:51 +00:00
|
|
|
* be called with obj->lock held.
|
|
|
|
*
|
|
|
|
* RETURNS
|
|
|
|
* Zero for success, or -errno
|
2014-07-01 10:57:54 +00:00
|
|
|
*/
|
2019-08-11 08:06:32 +00:00
|
|
|
int dma_resv_reserve_shared(struct dma_resv *obj, unsigned int num_fences)
|
2014-07-01 10:57:54 +00:00
|
|
|
{
|
2019-08-11 08:06:32 +00:00
|
|
|
struct dma_resv_list *old, *new;
|
2018-08-08 14:01:22 +00:00
|
|
|
unsigned int i, j, k, max;
|
2014-07-01 10:57:54 +00:00
|
|
|
|
2019-08-11 08:06:32 +00:00
|
|
|
dma_resv_assert_held(obj);
|
2017-06-13 08:26:46 +00:00
|
|
|
|
2019-08-11 08:06:32 +00:00
|
|
|
old = dma_resv_get_list(obj);
|
2014-07-01 10:57:54 +00:00
|
|
|
|
|
|
|
if (old && old->shared_max) {
|
2018-09-19 14:12:25 +00:00
|
|
|
if ((old->shared_count + num_fences) <= old->shared_max)
|
2014-07-01 10:57:54 +00:00
|
|
|
return 0;
|
2018-08-08 14:01:22 +00:00
|
|
|
else
|
2018-09-19 14:12:25 +00:00
|
|
|
max = max(old->shared_count + num_fences,
|
|
|
|
old->shared_max * 2);
|
2017-11-14 14:24:36 +00:00
|
|
|
} else {
|
2018-08-08 14:01:22 +00:00
|
|
|
max = 4;
|
2017-11-14 14:24:36 +00:00
|
|
|
}
|
2014-07-01 10:58:00 +00:00
|
|
|
|
2019-08-11 08:06:32 +00:00
|
|
|
new = dma_resv_list_alloc(max);
|
2018-08-08 14:01:22 +00:00
|
|
|
if (!new)
|
|
|
|
return -ENOMEM;
|
2014-07-01 10:57:54 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* no need to bump fence refcounts, rcu_read access
|
|
|
|
* requires the use of kref_get_unless_zero, and the
|
|
|
|
* references from the old struct are carried over to
|
|
|
|
* the new.
|
|
|
|
*/
|
2018-08-08 14:01:22 +00:00
|
|
|
for (i = 0, j = 0, k = max; i < (old ? old->shared_count : 0); ++i) {
|
|
|
|
struct dma_fence *fence;
|
2014-07-01 10:58:00 +00:00
|
|
|
|
2018-08-08 14:01:22 +00:00
|
|
|
fence = rcu_dereference_protected(old->shared[i],
|
2019-08-11 08:06:32 +00:00
|
|
|
dma_resv_held(obj));
|
2018-08-08 14:01:22 +00:00
|
|
|
if (dma_fence_is_signaled(fence))
|
|
|
|
RCU_INIT_POINTER(new->shared[--k], fence);
|
2017-11-14 14:24:35 +00:00
|
|
|
else
|
2018-08-08 14:01:22 +00:00
|
|
|
RCU_INIT_POINTER(new->shared[j++], fence);
|
2014-07-01 10:57:54 +00:00
|
|
|
}
|
2018-08-08 14:01:22 +00:00
|
|
|
new->shared_count = j;
|
2014-07-01 10:57:54 +00:00
|
|
|
|
2014-07-01 10:58:00 +00:00
|
|
|
/*
|
2019-07-12 08:03:14 +00:00
|
|
|
* We are not changing the effective set of fences here so can
|
|
|
|
* merely update the pointer to the new array; both existing
|
|
|
|
* readers and new readers will see exactly the same set of
|
|
|
|
* active (unsignaled) shared fences. Individual fences and the
|
|
|
|
* old array are protected by RCU and so will not vanish under
|
|
|
|
* the gaze of the rcu_read_lock() readers.
|
2014-07-01 10:58:00 +00:00
|
|
|
*/
|
2019-07-12 08:03:14 +00:00
|
|
|
rcu_assign_pointer(obj->fence, new);
|
2014-07-01 10:58:00 +00:00
|
|
|
|
2017-11-14 14:24:35 +00:00
|
|
|
if (!old)
|
2018-08-08 14:01:22 +00:00
|
|
|
return 0;
|
2014-07-01 10:58:00 +00:00
|
|
|
|
2017-11-14 14:24:35 +00:00
|
|
|
/* Drop the references to the signaled fences */
|
2019-07-12 08:03:13 +00:00
|
|
|
for (i = k; i < max; ++i) {
|
2018-08-08 14:01:22 +00:00
|
|
|
struct dma_fence *fence;
|
2017-11-14 14:24:35 +00:00
|
|
|
|
2018-08-08 14:01:22 +00:00
|
|
|
fence = rcu_dereference_protected(new->shared[i],
|
2019-08-11 08:06:32 +00:00
|
|
|
dma_resv_held(obj));
|
2018-08-08 14:01:22 +00:00
|
|
|
dma_fence_put(fence);
|
2017-11-14 14:24:35 +00:00
|
|
|
}
|
|
|
|
kfree_rcu(old, rcu);
|
2018-08-08 14:01:22 +00:00
|
|
|
|
|
|
|
return 0;
|
2014-07-01 10:57:54 +00:00
|
|
|
}
|
2019-08-11 08:06:32 +00:00
|
|
|
EXPORT_SYMBOL(dma_resv_reserve_shared);
|
2014-07-01 10:57:54 +00:00
|
|
|
|
2016-03-31 20:26:51 +00:00
|
|
|
/**
|
2019-08-11 08:06:32 +00:00
|
|
|
* dma_resv_add_shared_fence - Add a fence to a shared slot
|
2016-03-31 20:26:51 +00:00
|
|
|
* @obj: the reservation object
|
|
|
|
* @fence: the shared fence to add
|
|
|
|
*
|
2014-07-01 10:57:54 +00:00
|
|
|
* Add a fence to a shared slot, obj->lock must be held, and
|
2019-08-11 08:06:32 +00:00
|
|
|
* dma_resv_reserve_shared() has been called.
|
2014-07-01 10:57:54 +00:00
|
|
|
*/
|
2019-08-11 08:06:32 +00:00
|
|
|
void dma_resv_add_shared_fence(struct dma_resv *obj, struct dma_fence *fence)
|
2014-07-01 10:57:54 +00:00
|
|
|
{
|
2019-08-11 08:06:32 +00:00
|
|
|
struct dma_resv_list *fobj;
|
2019-08-05 09:14:27 +00:00
|
|
|
struct dma_fence *old;
|
2018-10-26 08:03:02 +00:00
|
|
|
unsigned int i, count;
|
2014-07-01 10:57:54 +00:00
|
|
|
|
2018-08-08 14:01:22 +00:00
|
|
|
dma_fence_get(fence);
|
|
|
|
|
2019-08-11 08:06:32 +00:00
|
|
|
dma_resv_assert_held(obj);
|
2017-06-13 08:26:46 +00:00
|
|
|
|
2019-08-11 08:06:32 +00:00
|
|
|
fobj = dma_resv_get_list(obj);
|
2018-10-26 08:03:02 +00:00
|
|
|
count = fobj->shared_count;
|
2014-07-01 10:57:54 +00:00
|
|
|
|
2019-08-14 18:24:01 +00:00
|
|
|
write_seqcount_begin(&obj->seq);
|
|
|
|
|
2018-10-26 08:03:02 +00:00
|
|
|
for (i = 0; i < count; ++i) {
|
2018-08-08 14:01:22 +00:00
|
|
|
|
2019-08-05 09:14:27 +00:00
|
|
|
old = rcu_dereference_protected(fobj->shared[i],
|
2019-08-11 08:06:32 +00:00
|
|
|
dma_resv_held(obj));
|
2019-08-05 09:14:27 +00:00
|
|
|
if (old->context == fence->context ||
|
|
|
|
dma_fence_is_signaled(old))
|
2018-08-08 14:01:22 +00:00
|
|
|
goto replace;
|
|
|
|
}
|
|
|
|
|
|
|
|
BUG_ON(fobj->shared_count >= fobj->shared_max);
|
2019-08-05 09:14:27 +00:00
|
|
|
old = NULL;
|
2018-10-26 08:03:02 +00:00
|
|
|
count++;
|
2018-08-08 14:01:22 +00:00
|
|
|
|
|
|
|
replace:
|
|
|
|
RCU_INIT_POINTER(fobj->shared[i], fence);
|
2018-10-26 08:03:02 +00:00
|
|
|
/* pointer update must be visible before we extend the shared_count */
|
|
|
|
smp_store_mb(fobj->shared_count, count);
|
2019-08-14 18:24:01 +00:00
|
|
|
|
|
|
|
write_seqcount_end(&obj->seq);
|
2019-08-05 09:14:27 +00:00
|
|
|
dma_fence_put(old);
|
2014-07-01 10:57:54 +00:00
|
|
|
}
|
2019-08-11 08:06:32 +00:00
|
|
|
EXPORT_SYMBOL(dma_resv_add_shared_fence);
|
2014-07-01 10:57:54 +00:00
|
|
|
|
2016-03-31 20:26:51 +00:00
|
|
|
/**
|
2019-08-11 08:06:32 +00:00
|
|
|
* dma_resv_add_excl_fence - Add an exclusive fence.
|
2016-03-31 20:26:51 +00:00
|
|
|
* @obj: the reservation object
|
|
|
|
* @fence: the shared fence to add
|
|
|
|
*
|
|
|
|
* Add a fence to the exclusive slot. The obj->lock must be held.
|
|
|
|
*/
|
2019-08-11 08:06:32 +00:00
|
|
|
void dma_resv_add_excl_fence(struct dma_resv *obj, struct dma_fence *fence)
|
2014-07-01 10:57:54 +00:00
|
|
|
{
|
2019-08-11 08:06:32 +00:00
|
|
|
struct dma_fence *old_fence = dma_resv_get_excl(obj);
|
|
|
|
struct dma_resv_list *old;
|
2014-07-01 10:57:54 +00:00
|
|
|
u32 i = 0;
|
|
|
|
|
2019-08-11 08:06:32 +00:00
|
|
|
dma_resv_assert_held(obj);
|
2017-06-13 08:26:46 +00:00
|
|
|
|
2019-08-11 08:06:32 +00:00
|
|
|
old = dma_resv_get_list(obj);
|
2014-07-01 10:58:00 +00:00
|
|
|
if (old)
|
2014-07-01 10:57:54 +00:00
|
|
|
i = old->shared_count;
|
|
|
|
|
|
|
|
if (fence)
|
2016-10-25 12:00:45 +00:00
|
|
|
dma_fence_get(fence);
|
2014-07-01 10:57:54 +00:00
|
|
|
|
2019-08-14 18:24:01 +00:00
|
|
|
write_seqcount_begin(&obj->seq);
|
|
|
|
/* write_seqcount_begin provides the necessary memory barrier */
|
|
|
|
RCU_INIT_POINTER(obj->fence_excl, fence);
|
2014-07-01 10:58:00 +00:00
|
|
|
if (old)
|
2019-08-14 18:24:01 +00:00
|
|
|
old->shared_count = 0;
|
|
|
|
write_seqcount_end(&obj->seq);
|
2014-07-01 10:57:54 +00:00
|
|
|
|
|
|
|
/* inplace update, no shared fences */
|
|
|
|
while (i--)
|
2016-10-25 12:00:45 +00:00
|
|
|
dma_fence_put(rcu_dereference_protected(old->shared[i],
|
2019-08-11 08:06:32 +00:00
|
|
|
dma_resv_held(obj)));
|
2014-07-01 10:57:54 +00:00
|
|
|
|
2017-08-07 21:32:21 +00:00
|
|
|
dma_fence_put(old_fence);
|
2014-07-01 10:57:54 +00:00
|
|
|
}
|
2019-08-11 08:06:32 +00:00
|
|
|
EXPORT_SYMBOL(dma_resv_add_excl_fence);
|
2014-07-01 10:58:00 +00:00
|
|
|
|
2017-08-10 17:01:48 +00:00
|
|
|
/**
|
2019-08-11 08:06:32 +00:00
|
|
|
* dma_resv_copy_fences - Copy all fences from src to dst.
|
2017-08-10 17:01:48 +00:00
|
|
|
* @dst: the destination reservation object
|
|
|
|
* @src: the source reservation object
|
|
|
|
*
|
2017-09-04 19:02:45 +00:00
|
|
|
* Copy all fences from src to dst. dst-lock must be held.
|
2017-08-10 17:01:48 +00:00
|
|
|
*/
|
2019-08-11 08:06:32 +00:00
|
|
|
int dma_resv_copy_fences(struct dma_resv *dst, struct dma_resv *src)
|
2017-08-10 17:01:48 +00:00
|
|
|
{
|
2019-08-11 08:06:32 +00:00
|
|
|
struct dma_resv_list *src_list, *dst_list;
|
2017-08-10 17:01:48 +00:00
|
|
|
struct dma_fence *old, *new;
|
2019-08-14 18:24:01 +00:00
|
|
|
unsigned i;
|
2017-08-10 17:01:48 +00:00
|
|
|
|
2019-08-11 08:06:32 +00:00
|
|
|
dma_resv_assert_held(dst);
|
2017-06-13 08:26:46 +00:00
|
|
|
|
2017-09-04 19:02:45 +00:00
|
|
|
rcu_read_lock();
|
2019-08-14 18:24:01 +00:00
|
|
|
src_list = rcu_dereference(src->fence);
|
2017-08-10 17:01:48 +00:00
|
|
|
|
2017-09-04 19:02:45 +00:00
|
|
|
retry:
|
2019-08-14 18:24:01 +00:00
|
|
|
if (src_list) {
|
|
|
|
unsigned shared_count = src_list->shared_count;
|
|
|
|
|
2017-09-04 19:02:45 +00:00
|
|
|
rcu_read_unlock();
|
|
|
|
|
2019-08-11 08:06:32 +00:00
|
|
|
dst_list = dma_resv_list_alloc(shared_count);
|
2017-08-10 17:01:48 +00:00
|
|
|
if (!dst_list)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2017-09-04 19:02:45 +00:00
|
|
|
rcu_read_lock();
|
2019-08-14 18:24:01 +00:00
|
|
|
src_list = rcu_dereference(src->fence);
|
|
|
|
if (!src_list || src_list->shared_count > shared_count) {
|
2017-09-04 19:02:45 +00:00
|
|
|
kfree(dst_list);
|
|
|
|
goto retry;
|
|
|
|
}
|
|
|
|
|
|
|
|
dst_list->shared_count = 0;
|
2019-08-14 18:24:01 +00:00
|
|
|
for (i = 0; i < src_list->shared_count; ++i) {
|
2017-09-04 19:02:45 +00:00
|
|
|
struct dma_fence *fence;
|
|
|
|
|
|
|
|
fence = rcu_dereference(src_list->shared[i]);
|
|
|
|
if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
|
|
|
|
&fence->flags))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (!dma_fence_get_rcu(fence)) {
|
2019-08-11 08:06:32 +00:00
|
|
|
dma_resv_list_free(dst_list);
|
2019-08-14 18:24:01 +00:00
|
|
|
src_list = rcu_dereference(src->fence);
|
2017-09-04 19:02:45 +00:00
|
|
|
goto retry;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (dma_fence_is_signaled(fence)) {
|
|
|
|
dma_fence_put(fence);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2017-11-02 20:03:36 +00:00
|
|
|
rcu_assign_pointer(dst_list->shared[dst_list->shared_count++], fence);
|
2017-09-04 19:02:45 +00:00
|
|
|
}
|
2017-08-10 17:01:48 +00:00
|
|
|
} else {
|
|
|
|
dst_list = NULL;
|
|
|
|
}
|
|
|
|
|
2019-08-14 18:24:01 +00:00
|
|
|
new = dma_fence_get_rcu_safe(&src->fence_excl);
|
2017-09-04 19:02:45 +00:00
|
|
|
rcu_read_unlock();
|
|
|
|
|
2019-08-11 08:06:32 +00:00
|
|
|
src_list = dma_resv_get_list(dst);
|
|
|
|
old = dma_resv_get_excl(dst);
|
2017-08-10 17:01:48 +00:00
|
|
|
|
2019-08-14 18:24:01 +00:00
|
|
|
write_seqcount_begin(&dst->seq);
|
|
|
|
/* write_seqcount_begin provides the necessary memory barrier */
|
|
|
|
RCU_INIT_POINTER(dst->fence_excl, new);
|
|
|
|
RCU_INIT_POINTER(dst->fence, dst_list);
|
|
|
|
write_seqcount_end(&dst->seq);
|
2017-08-10 17:01:48 +00:00
|
|
|
|
2019-08-11 08:06:32 +00:00
|
|
|
dma_resv_list_free(src_list);
|
2017-08-10 17:01:48 +00:00
|
|
|
dma_fence_put(old);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2019-08-11 08:06:32 +00:00
|
|
|
EXPORT_SYMBOL(dma_resv_copy_fences);
|
2017-08-10 17:01:48 +00:00
|
|
|
|
2016-03-31 20:26:51 +00:00
|
|
|
/**
|
2019-08-11 08:06:32 +00:00
|
|
|
* dma_resv_get_fences_rcu - Get an object's shared and exclusive
|
2016-03-31 20:26:51 +00:00
|
|
|
* fences without update side lock held
|
|
|
|
* @obj: the reservation object
|
|
|
|
* @pfence_excl: the returned exclusive fence (or NULL)
|
|
|
|
* @pshared_count: the number of shared fences returned
|
|
|
|
* @pshared: the array of shared fence ptrs returned (array is krealloc'd to
|
|
|
|
* the required size, and must be freed by caller)
|
|
|
|
*
|
2018-01-10 12:53:41 +00:00
|
|
|
* Retrieve all fences from the reservation object. If the pointer for the
|
|
|
|
* exclusive fence is not specified the fence is put into the array of the
|
|
|
|
* shared fences as well. Returns either zero or -ENOMEM.
|
2016-03-31 20:26:51 +00:00
|
|
|
*/
|
2019-08-11 08:06:32 +00:00
|
|
|
int dma_resv_get_fences_rcu(struct dma_resv *obj,
|
|
|
|
struct dma_fence **pfence_excl,
|
|
|
|
unsigned *pshared_count,
|
|
|
|
struct dma_fence ***pshared)
|
2014-07-01 10:58:00 +00:00
|
|
|
{
|
2016-10-25 12:00:45 +00:00
|
|
|
struct dma_fence **shared = NULL;
|
|
|
|
struct dma_fence *fence_excl;
|
2016-08-29 07:08:30 +00:00
|
|
|
unsigned int shared_count;
|
|
|
|
int ret = 1;
|
2014-07-01 10:58:00 +00:00
|
|
|
|
2016-08-29 07:08:30 +00:00
|
|
|
do {
|
2019-08-11 08:06:32 +00:00
|
|
|
struct dma_resv_list *fobj;
|
2019-08-14 18:24:01 +00:00
|
|
|
unsigned int i, seq;
|
2018-01-10 12:53:41 +00:00
|
|
|
size_t sz = 0;
|
2014-07-01 10:58:00 +00:00
|
|
|
|
2019-08-14 18:24:01 +00:00
|
|
|
shared_count = i = 0;
|
2014-07-01 10:58:00 +00:00
|
|
|
|
|
|
|
rcu_read_lock();
|
2019-08-14 18:24:01 +00:00
|
|
|
seq = read_seqcount_begin(&obj->seq);
|
2016-08-29 07:08:30 +00:00
|
|
|
|
2019-08-14 18:24:01 +00:00
|
|
|
fence_excl = rcu_dereference(obj->fence_excl);
|
2016-10-25 12:00:45 +00:00
|
|
|
if (fence_excl && !dma_fence_get_rcu(fence_excl))
|
2016-08-29 07:08:30 +00:00
|
|
|
goto unlock;
|
2014-07-01 10:58:00 +00:00
|
|
|
|
2019-08-14 18:24:01 +00:00
|
|
|
fobj = rcu_dereference(obj->fence);
|
2018-01-10 12:53:41 +00:00
|
|
|
if (fobj)
|
|
|
|
sz += sizeof(*shared) * fobj->shared_max;
|
|
|
|
|
|
|
|
if (!pfence_excl && fence_excl)
|
|
|
|
sz += sizeof(*shared);
|
|
|
|
|
|
|
|
if (sz) {
|
2016-10-25 12:00:45 +00:00
|
|
|
struct dma_fence **nshared;
|
2014-07-01 10:58:00 +00:00
|
|
|
|
|
|
|
nshared = krealloc(shared, sz,
|
|
|
|
GFP_NOWAIT | __GFP_NOWARN);
|
|
|
|
if (!nshared) {
|
|
|
|
rcu_read_unlock();
|
2019-06-04 12:53:23 +00:00
|
|
|
|
|
|
|
dma_fence_put(fence_excl);
|
|
|
|
fence_excl = NULL;
|
|
|
|
|
2014-07-01 10:58:00 +00:00
|
|
|
nshared = krealloc(shared, sz, GFP_KERNEL);
|
|
|
|
if (nshared) {
|
|
|
|
shared = nshared;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = -ENOMEM;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
shared = nshared;
|
2019-08-14 18:24:01 +00:00
|
|
|
shared_count = fobj ? fobj->shared_count : 0;
|
2014-07-01 10:58:00 +00:00
|
|
|
for (i = 0; i < shared_count; ++i) {
|
2016-08-29 07:08:30 +00:00
|
|
|
shared[i] = rcu_dereference(fobj->shared[i]);
|
2016-10-25 12:00:45 +00:00
|
|
|
if (!dma_fence_get_rcu(shared[i]))
|
2016-08-29 07:08:30 +00:00
|
|
|
break;
|
2014-07-01 10:58:00 +00:00
|
|
|
}
|
2016-08-29 07:08:30 +00:00
|
|
|
}
|
2014-07-01 10:58:00 +00:00
|
|
|
|
2019-08-14 18:24:01 +00:00
|
|
|
if (i != shared_count || read_seqcount_retry(&obj->seq, seq)) {
|
2016-08-29 07:08:30 +00:00
|
|
|
while (i--)
|
2016-10-25 12:00:45 +00:00
|
|
|
dma_fence_put(shared[i]);
|
|
|
|
dma_fence_put(fence_excl);
|
2016-08-29 07:08:30 +00:00
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = 0;
|
2014-07-01 10:58:00 +00:00
|
|
|
unlock:
|
|
|
|
rcu_read_unlock();
|
2016-08-29 07:08:30 +00:00
|
|
|
} while (ret);
|
|
|
|
|
2019-08-05 09:49:20 +00:00
|
|
|
if (pfence_excl)
|
|
|
|
*pfence_excl = fence_excl;
|
|
|
|
else if (fence_excl)
|
2019-09-22 07:49:00 +00:00
|
|
|
shared[shared_count++] = fence_excl;
|
2019-08-05 09:49:20 +00:00
|
|
|
|
2016-08-29 07:08:30 +00:00
|
|
|
if (!shared_count) {
|
2014-07-01 10:58:00 +00:00
|
|
|
kfree(shared);
|
2016-08-29 07:08:30 +00:00
|
|
|
shared = NULL;
|
2014-07-01 10:58:00 +00:00
|
|
|
}
|
2016-08-29 07:08:30 +00:00
|
|
|
|
|
|
|
*pshared_count = shared_count;
|
|
|
|
*pshared = shared;
|
2014-07-01 10:58:00 +00:00
|
|
|
return ret;
|
|
|
|
}
|
2019-08-11 08:06:32 +00:00
|
|
|
EXPORT_SYMBOL_GPL(dma_resv_get_fences_rcu);
|
2014-07-01 10:58:00 +00:00
|
|
|
|
2016-03-31 20:26:51 +00:00
|
|
|
/**
|
2019-08-11 08:06:32 +00:00
|
|
|
* dma_resv_wait_timeout_rcu - Wait on reservation's objects
|
2016-03-31 20:26:51 +00:00
|
|
|
* shared and/or exclusive fences.
|
|
|
|
* @obj: the reservation object
|
|
|
|
* @wait_all: if true, wait on all fences, else wait on just exclusive fence
|
|
|
|
* @intr: if true, do interruptible wait
|
|
|
|
* @timeout: timeout value in jiffies or zero to return immediately
|
|
|
|
*
|
|
|
|
* RETURNS
|
|
|
|
* Returns -ERESTARTSYS if interrupted, 0 if the wait timed out, or
|
|
|
|
* greater than zer on success.
|
|
|
|
*/
|
2019-08-11 08:06:32 +00:00
|
|
|
long dma_resv_wait_timeout_rcu(struct dma_resv *obj,
|
|
|
|
bool wait_all, bool intr,
|
|
|
|
unsigned long timeout)
|
2014-07-01 10:58:00 +00:00
|
|
|
{
|
2016-10-25 12:00:45 +00:00
|
|
|
struct dma_fence *fence;
|
2019-08-14 18:24:01 +00:00
|
|
|
unsigned seq, shared_count;
|
2016-11-07 21:16:16 +00:00
|
|
|
long ret = timeout ? timeout : 1;
|
2018-01-22 20:00:03 +00:00
|
|
|
int i;
|
2015-01-21 10:35:47 +00:00
|
|
|
|
2014-07-01 10:58:00 +00:00
|
|
|
retry:
|
2019-08-14 18:24:01 +00:00
|
|
|
shared_count = 0;
|
|
|
|
seq = read_seqcount_begin(&obj->seq);
|
2014-07-01 10:58:00 +00:00
|
|
|
rcu_read_lock();
|
2018-01-22 20:00:03 +00:00
|
|
|
i = -1;
|
2014-07-01 10:58:00 +00:00
|
|
|
|
2019-08-14 18:24:01 +00:00
|
|
|
fence = rcu_dereference(obj->fence_excl);
|
2017-08-10 17:01:49 +00:00
|
|
|
if (fence && !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
|
|
|
|
if (!dma_fence_get_rcu(fence))
|
|
|
|
goto unlock_retry;
|
|
|
|
|
|
|
|
if (dma_fence_is_signaled(fence)) {
|
|
|
|
dma_fence_put(fence);
|
|
|
|
fence = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
} else {
|
|
|
|
fence = NULL;
|
|
|
|
}
|
|
|
|
|
2018-01-22 20:00:03 +00:00
|
|
|
if (wait_all) {
|
2019-08-14 18:24:01 +00:00
|
|
|
struct dma_resv_list *fobj = rcu_dereference(obj->fence);
|
|
|
|
|
|
|
|
if (fobj)
|
|
|
|
shared_count = fobj->shared_count;
|
|
|
|
|
2018-01-22 20:00:03 +00:00
|
|
|
for (i = 0; !fence && i < shared_count; ++i) {
|
2016-10-25 12:00:45 +00:00
|
|
|
struct dma_fence *lfence = rcu_dereference(fobj->shared[i]);
|
2014-07-01 10:58:00 +00:00
|
|
|
|
2016-10-25 12:00:45 +00:00
|
|
|
if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
|
|
|
|
&lfence->flags))
|
2014-07-01 10:58:00 +00:00
|
|
|
continue;
|
|
|
|
|
2016-10-25 12:00:45 +00:00
|
|
|
if (!dma_fence_get_rcu(lfence))
|
2014-07-01 10:58:00 +00:00
|
|
|
goto unlock_retry;
|
|
|
|
|
2016-10-25 12:00:45 +00:00
|
|
|
if (dma_fence_is_signaled(lfence)) {
|
|
|
|
dma_fence_put(lfence);
|
2014-07-01 10:58:00 +00:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
fence = lfence;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
rcu_read_unlock();
|
|
|
|
if (fence) {
|
2019-08-14 18:24:01 +00:00
|
|
|
if (read_seqcount_retry(&obj->seq, seq)) {
|
|
|
|
dma_fence_put(fence);
|
|
|
|
goto retry;
|
|
|
|
}
|
|
|
|
|
2016-10-25 12:00:45 +00:00
|
|
|
ret = dma_fence_wait_timeout(fence, intr, ret);
|
|
|
|
dma_fence_put(fence);
|
2014-07-01 10:58:00 +00:00
|
|
|
if (ret > 0 && wait_all && (i + 1 < shared_count))
|
|
|
|
goto retry;
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
unlock_retry:
|
|
|
|
rcu_read_unlock();
|
|
|
|
goto retry;
|
|
|
|
}
|
2019-08-11 08:06:32 +00:00
|
|
|
EXPORT_SYMBOL_GPL(dma_resv_wait_timeout_rcu);
|
2014-07-01 10:58:00 +00:00
|
|
|
|
|
|
|
|
2019-08-11 08:06:32 +00:00
|
|
|
static inline int dma_resv_test_signaled_single(struct dma_fence *passed_fence)
|
2014-07-01 10:58:00 +00:00
|
|
|
{
|
2016-10-25 12:00:45 +00:00
|
|
|
struct dma_fence *fence, *lfence = passed_fence;
|
2014-07-01 10:58:00 +00:00
|
|
|
int ret = 1;
|
|
|
|
|
2016-10-25 12:00:45 +00:00
|
|
|
if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &lfence->flags)) {
|
|
|
|
fence = dma_fence_get_rcu(lfence);
|
2014-07-01 10:58:00 +00:00
|
|
|
if (!fence)
|
|
|
|
return -1;
|
|
|
|
|
2016-10-25 12:00:45 +00:00
|
|
|
ret = !!dma_fence_is_signaled(fence);
|
|
|
|
dma_fence_put(fence);
|
2014-07-01 10:58:00 +00:00
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2016-03-31 20:26:51 +00:00
|
|
|
/**
|
2019-08-11 08:06:32 +00:00
|
|
|
* dma_resv_test_signaled_rcu - Test if a reservation object's
|
2016-03-31 20:26:51 +00:00
|
|
|
* fences have been signaled.
|
|
|
|
* @obj: the reservation object
|
|
|
|
* @test_all: if true, test all fences, otherwise only test the exclusive
|
|
|
|
* fence
|
|
|
|
*
|
|
|
|
* RETURNS
|
|
|
|
* true if all fences signaled, else false
|
|
|
|
*/
|
2019-08-11 08:06:32 +00:00
|
|
|
bool dma_resv_test_signaled_rcu(struct dma_resv *obj, bool test_all)
|
2014-07-01 10:58:00 +00:00
|
|
|
{
|
2019-08-14 18:24:01 +00:00
|
|
|
unsigned seq, shared_count;
|
2016-08-29 07:08:32 +00:00
|
|
|
int ret;
|
2014-07-01 10:58:00 +00:00
|
|
|
|
2016-08-29 07:08:32 +00:00
|
|
|
rcu_read_lock();
|
2014-07-01 10:58:00 +00:00
|
|
|
retry:
|
2016-08-29 07:08:32 +00:00
|
|
|
ret = true;
|
2019-08-14 18:24:01 +00:00
|
|
|
shared_count = 0;
|
|
|
|
seq = read_seqcount_begin(&obj->seq);
|
2014-07-01 10:58:00 +00:00
|
|
|
|
|
|
|
if (test_all) {
|
|
|
|
unsigned i;
|
|
|
|
|
2019-08-14 18:24:01 +00:00
|
|
|
struct dma_resv_list *fobj = rcu_dereference(obj->fence);
|
|
|
|
|
|
|
|
if (fobj)
|
|
|
|
shared_count = fobj->shared_count;
|
|
|
|
|
2014-07-01 10:58:00 +00:00
|
|
|
for (i = 0; i < shared_count; ++i) {
|
2016-10-25 12:00:45 +00:00
|
|
|
struct dma_fence *fence = rcu_dereference(fobj->shared[i]);
|
2014-07-01 10:58:00 +00:00
|
|
|
|
2019-08-11 08:06:32 +00:00
|
|
|
ret = dma_resv_test_signaled_single(fence);
|
2014-07-01 10:58:00 +00:00
|
|
|
if (ret < 0)
|
2016-08-29 07:08:32 +00:00
|
|
|
goto retry;
|
2014-07-01 10:58:00 +00:00
|
|
|
else if (!ret)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2019-08-14 18:24:01 +00:00
|
|
|
if (read_seqcount_retry(&obj->seq, seq))
|
2019-08-06 12:19:33 +00:00
|
|
|
goto retry;
|
2014-07-01 10:58:00 +00:00
|
|
|
}
|
|
|
|
|
2019-08-14 18:24:01 +00:00
|
|
|
if (!shared_count) {
|
|
|
|
struct dma_fence *fence_excl = rcu_dereference(obj->fence_excl);
|
|
|
|
|
|
|
|
if (fence_excl) {
|
|
|
|
ret = dma_resv_test_signaled_single(fence_excl);
|
|
|
|
if (ret < 0)
|
|
|
|
goto retry;
|
|
|
|
|
|
|
|
if (read_seqcount_retry(&obj->seq, seq))
|
|
|
|
goto retry;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-07-01 10:58:00 +00:00
|
|
|
rcu_read_unlock();
|
|
|
|
return ret;
|
|
|
|
}
|
2019-08-11 08:06:32 +00:00
|
|
|
EXPORT_SYMBOL_GPL(dma_resv_test_signaled_rcu);
|