Re: [Intel-gfx] [PATCH 2/7] dma-buf: Rename dma_resv helpers from _rcu to _unlocked (v2)
Ack on all naming. -Daniel BTW As long as Jason nor you object I will prepare patches for the rename of the functions. Regards, Christian. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/7] dma-buf: Rename dma_resv helpers from _rcu to _unlocked (v2)
Am 01.06.21 um 16:34 schrieb Daniel Vetter:
On Thu, May 27, 2021 at 03:41:02PM +0200, Christian König wrote:
Am 27.05.21 um 15:25 schrieb Daniel Vetter:
On Thu, May 27, 2021 at 1:59 PM Christian König
wrote:
Am 27.05.21 um 12:39 schrieb Daniel Vetter:
On Wed, May 26, 2021 at 12:57:40PM +0200, Christian König wrote:
Am 25.05.21 um 23:17 schrieb Jason Ekstrand:
None of these helpers actually leak any RCU details to the caller. They
all assume you have a genuine reference, take the RCU read lock, and
retry if needed. Naming them with an _rcu is likely to cause callers
more panic than needed.
I'm really wondering if we need this postfix in the first place.
If we use the right rcu_dereference_check() macro then those functions can
be called with both the reservation object locked and unlocked. It shouldn't
matter to them.
But getting rid of the _rcu postfix sounds like a good idea in general to
me.
So does that count as an ack or not? If yes I think we should land this
patch right away, since it's going to conflict real fast badly.
I had some follow up discussion with Jason and I would rather like to
switch to using rcu_dereference_check() in all places and completely
remove the _rcu postfix.
Hm, I'm not sure whether spreading _rcu tricks further is an
especially bright idea. At least i915 is full of very clever _rcu
tricks, and encouraging drivers to roll out their own _rcu everywhere
is probably not in our best interest. Some fast-path checking is imo
ok, but that's it. Especially once we get into the entire
SLAB_TYPESAFE_BY_RCU business it becomes really nasty really quickly.
Oh, yes completely agree. SLAB_TYPESAFE_BY_RCU is optimizing for the wrong
use case I think.
You save a bit of overhead while freeing fences, but in return you have
extra overhead while adding fences to the dma_resv object.
Getting way off topic, but I'm wondering whether the entire rcu business
is really worth it for dma_fence.
Mostly we manipulate dma_resv while holding dma_resv anyway. There's maybe
a few waits and stuff, but I'm not sure whether the dma_resv_lock +
dma_fence_get + dma_resv_unlock + dma_fence_put really matter. And if you
have lock contention on a single buffer you've lost anyway.
At that point I think we have maybe some lockless tricks in the evict
code, but then again once you're evicting it's probably going pretty bad
already.
So SLAB_TYPESAFE_BY_RCU is something I want to analyze for i915 whether
it's really worth it and was justified, or whether we should drop it. But
I'm wondering whether we should drop rcu for fences outright. Would be
quite some audit to check out where it's used.
From i915 side we've done these lockless tricks back when
dev->struct_mutex was a thing and alwas contended. But with per-obj
locking now happening for real with dma-resv, that's probably not
justified.
But then looking at git history the rcu in dma_resv is older than that,
and was justified with ttm.
Scratching my head when and why TTM should have ever needed some
lockless operation when that was added? We do have some now, but just
because they where available.
On the other hand I'm pretty sure that we can make the whole RCU
handling in the dma_resv object much less painful. Basic problem here is
that we have two pointers instead of one, e.g. the excl fence and/or the
shared fences.
If we could move the exclusive fence pointer into the shared fences most
of the trouble would go away suddenly.
The other thing we should certainly have is more use case based
iterators. E.g. something like dma_resv_for_each_sync_fence(...) {...}.
Regards,
Christian.
That's why I'm slightly leaning towards _unlocked variants, except we
do use those in lots of places where we hold dma_resv_lock too. So not
sure what's the best plan overall here.
Well what function names are we actually talking about?
For the dma_resv_get_excl_rcu() case I agree we should probably name that to
dma_resv_get_excl_unlocked() because it makes no sense at all to use this
function while holding the lock.
But for the following functions:
dma_resv_get_fences_rcu
dma_resv_wait_timeout_rcu
dma_resv_test_signaled_rcu
I think we should just drop the _rcu naming because those are supposed to
work independent if the resv lock is held or not.
Ack on all naming.
-Daniel
Regards,
Christian.
-Daniel
But yes I see the pain of rebasing this as well.
Christian.
-Daniel
Christian.
v2 (Jason Ekstrand):
- Fix function argument indentation
Signed-off-by: Jason Ekstrand
Suggested-by: Daniel Vetter
Cc: Christian König
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: Lucas Stach
Cc: Rob Clark
Cc: Sean Paul
Cc: Huang Rui
Cc: Gerd Hoffmann
Cc: VMware Graphics
---
drivers/dma-buf/dma-buf.c | 4 +--
drivers/dma-buf/dma-resv.c| 28 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++--
Re: [Intel-gfx] [PATCH 2/7] dma-buf: Rename dma_resv helpers from _rcu to _unlocked (v2)
On Thu, May 27, 2021 at 03:41:02PM +0200, Christian König wrote: > Am 27.05.21 um 15:25 schrieb Daniel Vetter: > > On Thu, May 27, 2021 at 1:59 PM Christian König > > wrote: > > > Am 27.05.21 um 12:39 schrieb Daniel Vetter: > > > > On Wed, May 26, 2021 at 12:57:40PM +0200, Christian König wrote: > > > > > Am 25.05.21 um 23:17 schrieb Jason Ekstrand: > > > > > > None of these helpers actually leak any RCU details to the caller. > > > > > > They > > > > > > all assume you have a genuine reference, take the RCU read lock, and > > > > > > retry if needed. Naming them with an _rcu is likely to cause > > > > > > callers > > > > > > more panic than needed. > > > > > I'm really wondering if we need this postfix in the first place. > > > > > > > > > > If we use the right rcu_dereference_check() macro then those > > > > > functions can > > > > > be called with both the reservation object locked and unlocked. It > > > > > shouldn't > > > > > matter to them. > > > > > > > > > > But getting rid of the _rcu postfix sounds like a good idea in > > > > > general to > > > > > me. > > > > So does that count as an ack or not? If yes I think we should land this > > > > patch right away, since it's going to conflict real fast badly. > > > I had some follow up discussion with Jason and I would rather like to > > > switch to using rcu_dereference_check() in all places and completely > > > remove the _rcu postfix. > > Hm, I'm not sure whether spreading _rcu tricks further is an > > especially bright idea. At least i915 is full of very clever _rcu > > tricks, and encouraging drivers to roll out their own _rcu everywhere > > is probably not in our best interest. Some fast-path checking is imo > > ok, but that's it. Especially once we get into the entire > > SLAB_TYPESAFE_BY_RCU business it becomes really nasty really quickly. > > Oh, yes completely agree. SLAB_TYPESAFE_BY_RCU is optimizing for the wrong > use case I think. > > You save a bit of overhead while freeing fences, but in return you have > extra overhead while adding fences to the dma_resv object. Getting way off topic, but I'm wondering whether the entire rcu business is really worth it for dma_fence. Mostly we manipulate dma_resv while holding dma_resv anyway. There's maybe a few waits and stuff, but I'm not sure whether the dma_resv_lock + dma_fence_get + dma_resv_unlock + dma_fence_put really matter. And if you have lock contention on a single buffer you've lost anyway. At that point I think we have maybe some lockless tricks in the evict code, but then again once you're evicting it's probably going pretty bad already. So SLAB_TYPESAFE_BY_RCU is something I want to analyze for i915 whether it's really worth it and was justified, or whether we should drop it. But I'm wondering whether we should drop rcu for fences outright. Would be quite some audit to check out where it's used. >From i915 side we've done these lockless tricks back when dev->struct_mutex was a thing and alwas contended. But with per-obj locking now happening for real with dma-resv, that's probably not justified. But then looking at git history the rcu in dma_resv is older than that, and was justified with ttm. > > That's why I'm slightly leaning towards _unlocked variants, except we > > do use those in lots of places where we hold dma_resv_lock too. So not > > sure what's the best plan overall here. > > Well what function names are we actually talking about? > > For the dma_resv_get_excl_rcu() case I agree we should probably name that to > dma_resv_get_excl_unlocked() because it makes no sense at all to use this > function while holding the lock. > > But for the following functions: > dma_resv_get_fences_rcu > dma_resv_wait_timeout_rcu > dma_resv_test_signaled_rcu > > I think we should just drop the _rcu naming because those are supposed to > work independent if the resv lock is held or not. Ack on all naming. -Daniel > > Regards, > Christian. > > > -Daniel > > > > > But yes I see the pain of rebasing this as well. > > > > > > Christian. > > > > > > > -Daniel > > > > > > > > > Christian. > > > > > > > > > > > v2 (Jason Ekstrand): > > > > > > - Fix function argument indentation > > > > > > > > > > > > Signed-off-by: Jason Ekstrand > > > > > > Suggested-by: Daniel Vetter > > > > > > Cc: Christian König > > > > > > Cc: Maarten Lankhorst > > > > > > Cc: Maxime Ripard > > > > > > Cc: Thomas Zimmermann > > > > > > Cc: Lucas Stach > > > > > > Cc: Rob Clark > > > > > > Cc: Sean Paul > > > > > > Cc: Huang Rui > > > > > > Cc: Gerd Hoffmann > > > > > > Cc: VMware Graphics > > > > > > --- > > > > > > drivers/dma-buf/dma-buf.c | 4 +-- > > > > > > drivers/dma-buf/dma-resv.c| 28 > > > > > > +-- > > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++-- > > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +- > > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4 +--
Re: [Intel-gfx] [PATCH 2/7] dma-buf: Rename dma_resv helpers from _rcu to _unlocked (v2)
Am 27.05.21 um 15:25 schrieb Daniel Vetter: On Thu, May 27, 2021 at 1:59 PM Christian König wrote: Am 27.05.21 um 12:39 schrieb Daniel Vetter: On Wed, May 26, 2021 at 12:57:40PM +0200, Christian König wrote: Am 25.05.21 um 23:17 schrieb Jason Ekstrand: None of these helpers actually leak any RCU details to the caller. They all assume you have a genuine reference, take the RCU read lock, and retry if needed. Naming them with an _rcu is likely to cause callers more panic than needed. I'm really wondering if we need this postfix in the first place. If we use the right rcu_dereference_check() macro then those functions can be called with both the reservation object locked and unlocked. It shouldn't matter to them. But getting rid of the _rcu postfix sounds like a good idea in general to me. So does that count as an ack or not? If yes I think we should land this patch right away, since it's going to conflict real fast badly. I had some follow up discussion with Jason and I would rather like to switch to using rcu_dereference_check() in all places and completely remove the _rcu postfix. Hm, I'm not sure whether spreading _rcu tricks further is an especially bright idea. At least i915 is full of very clever _rcu tricks, and encouraging drivers to roll out their own _rcu everywhere is probably not in our best interest. Some fast-path checking is imo ok, but that's it. Especially once we get into the entire SLAB_TYPESAFE_BY_RCU business it becomes really nasty really quickly. Oh, yes completely agree. SLAB_TYPESAFE_BY_RCU is optimizing for the wrong use case I think. You save a bit of overhead while freeing fences, but in return you have extra overhead while adding fences to the dma_resv object. That's why I'm slightly leaning towards _unlocked variants, except we do use those in lots of places where we hold dma_resv_lock too. So not sure what's the best plan overall here. Well what function names are we actually talking about? For the dma_resv_get_excl_rcu() case I agree we should probably name that to dma_resv_get_excl_unlocked() because it makes no sense at all to use this function while holding the lock. But for the following functions: dma_resv_get_fences_rcu dma_resv_wait_timeout_rcu dma_resv_test_signaled_rcu I think we should just drop the _rcu naming because those are supposed to work independent if the resv lock is held or not. Regards, Christian. -Daniel But yes I see the pain of rebasing this as well. Christian. -Daniel Christian. v2 (Jason Ekstrand): - Fix function argument indentation Signed-off-by: Jason Ekstrand Suggested-by: Daniel Vetter Cc: Christian König Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: Lucas Stach Cc: Rob Clark Cc: Sean Paul Cc: Huang Rui Cc: Gerd Hoffmann Cc: VMware Graphics --- drivers/dma-buf/dma-buf.c | 4 +-- drivers/dma-buf/dma-resv.c| 28 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 6 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c| 4 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 4 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 6 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 14 +- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 ++-- drivers/gpu/drm/drm_gem.c | 10 +++ drivers/gpu/drm/drm_gem_atomic_helper.c | 2 +- drivers/gpu/drm/etnaviv/etnaviv_gem.c | 7 ++--- drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 8 +++--- drivers/gpu/drm/i915/display/intel_display.c | 2 +- drivers/gpu/drm/i915/dma_resv_utils.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_busy.c | 2 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +- drivers/gpu/drm/i915/gem/i915_gem_object.h| 2 +- drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 4 +-- drivers/gpu/drm/i915/gem/i915_gem_wait.c | 10 +++ drivers/gpu/drm/i915/i915_request.c | 6 ++-- drivers/gpu/drm/i915/i915_sw_fence.c | 4 +-- drivers/gpu/drm/msm/msm_gem.c | 3 +- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 4 +-- drivers/gpu/drm/panfrost/panfrost_drv.c | 4 +-- drivers/gpu/drm/panfrost/panfrost_job.c | 2 +- drivers/gpu/drm/radeon/radeon_gem.c | 6 ++-- drivers/gpu/drm/radeon/radeon_mn.c| 4 +-- drivers/gpu/drm/ttm/ttm_bo.c | 18 ++-- drivers/gpu/drm/vgem/vgem_fence.c | 4 +-- drivers/gpu/drm/virtio/virtgpu_ioctl.c| 6 ++-- drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 2 +- include/linux/dma-resv.h | 18
Re: [Intel-gfx] [PATCH 2/7] dma-buf: Rename dma_resv helpers from _rcu to _unlocked (v2)
On Thu, May 27, 2021 at 1:59 PM Christian König wrote: > > Am 27.05.21 um 12:39 schrieb Daniel Vetter: > > On Wed, May 26, 2021 at 12:57:40PM +0200, Christian König wrote: > >> Am 25.05.21 um 23:17 schrieb Jason Ekstrand: > >>> None of these helpers actually leak any RCU details to the caller. They > >>> all assume you have a genuine reference, take the RCU read lock, and > >>> retry if needed. Naming them with an _rcu is likely to cause callers > >>> more panic than needed. > >> I'm really wondering if we need this postfix in the first place. > >> > >> If we use the right rcu_dereference_check() macro then those functions can > >> be called with both the reservation object locked and unlocked. It > >> shouldn't > >> matter to them. > >> > >> But getting rid of the _rcu postfix sounds like a good idea in general to > >> me. > > So does that count as an ack or not? If yes I think we should land this > > patch right away, since it's going to conflict real fast badly. > > I had some follow up discussion with Jason and I would rather like to > switch to using rcu_dereference_check() in all places and completely > remove the _rcu postfix. Hm, I'm not sure whether spreading _rcu tricks further is an especially bright idea. At least i915 is full of very clever _rcu tricks, and encouraging drivers to roll out their own _rcu everywhere is probably not in our best interest. Some fast-path checking is imo ok, but that's it. Especially once we get into the entire SLAB_TYPESAFE_BY_RCU business it becomes really nasty really quickly. That's why I'm slightly leaning towards _unlocked variants, except we do use those in lots of places where we hold dma_resv_lock too. So not sure what's the best plan overall here. -Daniel > But yes I see the pain of rebasing this as well. > > Christian. > > > -Daniel > > > >> Christian. > >> > >>> v2 (Jason Ekstrand): > >>>- Fix function argument indentation > >>> > >>> Signed-off-by: Jason Ekstrand > >>> Suggested-by: Daniel Vetter > >>> Cc: Christian König > >>> Cc: Maarten Lankhorst > >>> Cc: Maxime Ripard > >>> Cc: Thomas Zimmermann > >>> Cc: Lucas Stach > >>> Cc: Rob Clark > >>> Cc: Sean Paul > >>> Cc: Huang Rui > >>> Cc: Gerd Hoffmann > >>> Cc: VMware Graphics > >>> --- > >>>drivers/dma-buf/dma-buf.c | 4 +-- > >>>drivers/dma-buf/dma-resv.c| 28 +-- > >>>drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++-- > >>>drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +- > >>>drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4 +-- > >>>drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 6 ++-- > >>>drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c| 4 +-- > >>>drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 4 +-- > >>>drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 6 ++-- > >>>drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 14 +- > >>>.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 ++-- > >>>drivers/gpu/drm/drm_gem.c | 10 +++ > >>>drivers/gpu/drm/drm_gem_atomic_helper.c | 2 +- > >>>drivers/gpu/drm/etnaviv/etnaviv_gem.c | 7 ++--- > >>>drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 8 +++--- > >>>drivers/gpu/drm/i915/display/intel_display.c | 2 +- > >>>drivers/gpu/drm/i915/dma_resv_utils.c | 2 +- > >>>drivers/gpu/drm/i915/gem/i915_gem_busy.c | 2 +- > >>>.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +- > >>>drivers/gpu/drm/i915/gem/i915_gem_object.h| 2 +- > >>>drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 4 +-- > >>>drivers/gpu/drm/i915/gem/i915_gem_wait.c | 10 +++ > >>>drivers/gpu/drm/i915/i915_request.c | 6 ++-- > >>>drivers/gpu/drm/i915/i915_sw_fence.c | 4 +-- > >>>drivers/gpu/drm/msm/msm_gem.c | 3 +- > >>>drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +- > >>>drivers/gpu/drm/nouveau/nouveau_gem.c | 4 +-- > >>>drivers/gpu/drm/panfrost/panfrost_drv.c | 4 +-- > >>>drivers/gpu/drm/panfrost/panfrost_job.c | 2 +- > >>>drivers/gpu/drm/radeon/radeon_gem.c | 6 ++-- > >>>drivers/gpu/drm/radeon/radeon_mn.c| 4 +-- > >>>drivers/gpu/drm/ttm/ttm_bo.c | 18 ++-- > >>>drivers/gpu/drm/vgem/vgem_fence.c | 4 +-- > >>>drivers/gpu/drm/virtio/virtgpu_ioctl.c| 6 ++-- > >>>drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 2 +- > >>>include/linux/dma-resv.h | 18 ++-- > >>>36 files changed, 108 insertions(+), 110 deletions(-) > >>> > >>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > >>> index f264b70c383eb..ed6451d55d663 100644 > >>> --- a/drivers/dma-buf/dma-buf.c > >>> +++ b/drivers/dma-buf/dma-buf.c > >>> @@ -1147,8 +1147,8 @@ static int __dma_buf_begin_cpu_access(struct > >>> dma_buf *dmabuf, > >>> long ret; > >>>
Re: [Intel-gfx] [PATCH 2/7] dma-buf: Rename dma_resv helpers from _rcu to _unlocked (v2)
On Thu, May 27, 2021 at 1:59 PM Christian König wrote: > Am 27.05.21 um 12:39 schrieb Daniel Vetter: > > On Wed, May 26, 2021 at 12:57:40PM +0200, Christian König wrote: > >> Am 25.05.21 um 23:17 schrieb Jason Ekstrand: > >>> None of these helpers actually leak any RCU details to the caller. They > >>> all assume you have a genuine reference, take the RCU read lock, and > >>> retry if needed. Naming them with an _rcu is likely to cause callers > >>> more panic than needed. > >> I'm really wondering if we need this postfix in the first place. > >> > >> If we use the right rcu_dereference_check() macro then those functions can > >> be called with both the reservation object locked and unlocked. It > >> shouldn't > >> matter to them. > >> > >> But getting rid of the _rcu postfix sounds like a good idea in general to > >> me. > > So does that count as an ack or not? If yes I think we should land this > > patch right away, since it's going to conflict real fast badly. > > I had some follow up discussion with Jason and I would rather like to > switch to using rcu_dereference_check() in all places and completely > remove the _rcu postfix. > > But yes I see the pain of rebasing this as well. > > Christian. > > > -Daniel > > > >> Christian. > >> > >>> v2 (Jason Ekstrand): > >>>- Fix function argument indentation > >>> > >>> Signed-off-by: Jason Ekstrand > >>> Suggested-by: Daniel Vetter > >>> Cc: Christian König > >>> Cc: Maarten Lankhorst > >>> Cc: Maxime Ripard > >>> Cc: Thomas Zimmermann > >>> Cc: Lucas Stach > >>> Cc: Rob Clark > >>> Cc: Sean Paul > >>> Cc: Huang Rui > >>> Cc: Gerd Hoffmann > >>> Cc: VMware Graphics > >>> --- > >>>drivers/dma-buf/dma-buf.c | 4 +-- > >>>drivers/dma-buf/dma-resv.c| 28 +-- > >>>drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++-- > >>>drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +- > >>>drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4 +-- > >>>drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 6 ++-- > >>>drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c| 4 +-- > >>>drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 4 +-- > >>>drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 6 ++-- > >>>drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 14 +- > >>>.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 ++-- > >>>drivers/gpu/drm/drm_gem.c | 10 +++ > >>>drivers/gpu/drm/drm_gem_atomic_helper.c | 2 +- > >>>drivers/gpu/drm/etnaviv/etnaviv_gem.c | 7 ++--- > >>>drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 8 +++--- > >>>drivers/gpu/drm/i915/display/intel_display.c | 2 +- > >>>drivers/gpu/drm/i915/dma_resv_utils.c | 2 +- > >>>drivers/gpu/drm/i915/gem/i915_gem_busy.c | 2 +- > >>>.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +- > >>>drivers/gpu/drm/i915/gem/i915_gem_object.h| 2 +- > >>>drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 4 +-- > >>>drivers/gpu/drm/i915/gem/i915_gem_wait.c | 10 +++ > >>>drivers/gpu/drm/i915/i915_request.c | 6 ++-- > >>>drivers/gpu/drm/i915/i915_sw_fence.c | 4 +-- > >>>drivers/gpu/drm/msm/msm_gem.c | 3 +- > >>>drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +- > >>>drivers/gpu/drm/nouveau/nouveau_gem.c | 4 +-- > >>>drivers/gpu/drm/panfrost/panfrost_drv.c | 4 +-- > >>>drivers/gpu/drm/panfrost/panfrost_job.c | 2 +- > >>>drivers/gpu/drm/radeon/radeon_gem.c | 6 ++-- > >>>drivers/gpu/drm/radeon/radeon_mn.c| 4 +-- > >>>drivers/gpu/drm/ttm/ttm_bo.c | 18 ++-- > >>>drivers/gpu/drm/vgem/vgem_fence.c | 4 +-- > >>>drivers/gpu/drm/virtio/virtgpu_ioctl.c| 6 ++-- > >>>drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 2 +- > >>>include/linux/dma-resv.h | 18 ++-- > >>>36 files changed, 108 insertions(+), 110 deletions(-) > >>> > >>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > >>> index f264b70c383eb..ed6451d55d663 100644 > >>> --- a/drivers/dma-buf/dma-buf.c > >>> +++ b/drivers/dma-buf/dma-buf.c > >>> @@ -1147,8 +1147,8 @@ static int __dma_buf_begin_cpu_access(struct > >>> dma_buf *dmabuf, > >>> long ret; > >>> /* Wait on any implicit rendering fences */ > >>> - ret = dma_resv_wait_timeout_rcu(resv, write, true, > >>> - MAX_SCHEDULE_TIMEOUT); > >>> + ret = dma_resv_wait_timeout_unlocked(resv, write, true, > >>> +MAX_SCHEDULE_TIMEOUT); > >>> if (ret < 0) > >>> return ret; > >>> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c > >>> index 6ddbeb5dfbf65..d6f1ed4cd4d55 100644 > >>> --- a/drivers/dma-buf/dma-resv.c > >>> +++ b/drivers/dma-buf/dma-resv.c > >>> @@
Re: [Intel-gfx] [PATCH 2/7] dma-buf: Rename dma_resv helpers from _rcu to _unlocked (v2)
Am 27.05.21 um 12:39 schrieb Daniel Vetter: On Wed, May 26, 2021 at 12:57:40PM +0200, Christian König wrote: Am 25.05.21 um 23:17 schrieb Jason Ekstrand: None of these helpers actually leak any RCU details to the caller. They all assume you have a genuine reference, take the RCU read lock, and retry if needed. Naming them with an _rcu is likely to cause callers more panic than needed. I'm really wondering if we need this postfix in the first place. If we use the right rcu_dereference_check() macro then those functions can be called with both the reservation object locked and unlocked. It shouldn't matter to them. But getting rid of the _rcu postfix sounds like a good idea in general to me. So does that count as an ack or not? If yes I think we should land this patch right away, since it's going to conflict real fast badly. I had some follow up discussion with Jason and I would rather like to switch to using rcu_dereference_check() in all places and completely remove the _rcu postfix. But yes I see the pain of rebasing this as well. Christian. -Daniel Christian. v2 (Jason Ekstrand): - Fix function argument indentation Signed-off-by: Jason Ekstrand Suggested-by: Daniel Vetter Cc: Christian König Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: Lucas Stach Cc: Rob Clark Cc: Sean Paul Cc: Huang Rui Cc: Gerd Hoffmann Cc: VMware Graphics --- drivers/dma-buf/dma-buf.c | 4 +-- drivers/dma-buf/dma-resv.c| 28 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 6 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c| 4 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 4 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 6 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 14 +- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 ++-- drivers/gpu/drm/drm_gem.c | 10 +++ drivers/gpu/drm/drm_gem_atomic_helper.c | 2 +- drivers/gpu/drm/etnaviv/etnaviv_gem.c | 7 ++--- drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 8 +++--- drivers/gpu/drm/i915/display/intel_display.c | 2 +- drivers/gpu/drm/i915/dma_resv_utils.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_busy.c | 2 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +- drivers/gpu/drm/i915/gem/i915_gem_object.h| 2 +- drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 4 +-- drivers/gpu/drm/i915/gem/i915_gem_wait.c | 10 +++ drivers/gpu/drm/i915/i915_request.c | 6 ++-- drivers/gpu/drm/i915/i915_sw_fence.c | 4 +-- drivers/gpu/drm/msm/msm_gem.c | 3 +- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 4 +-- drivers/gpu/drm/panfrost/panfrost_drv.c | 4 +-- drivers/gpu/drm/panfrost/panfrost_job.c | 2 +- drivers/gpu/drm/radeon/radeon_gem.c | 6 ++-- drivers/gpu/drm/radeon/radeon_mn.c| 4 +-- drivers/gpu/drm/ttm/ttm_bo.c | 18 ++-- drivers/gpu/drm/vgem/vgem_fence.c | 4 +-- drivers/gpu/drm/virtio/virtgpu_ioctl.c| 6 ++-- drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 2 +- include/linux/dma-resv.h | 18 ++-- 36 files changed, 108 insertions(+), 110 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index f264b70c383eb..ed6451d55d663 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -1147,8 +1147,8 @@ static int __dma_buf_begin_cpu_access(struct dma_buf *dmabuf, long ret; /* Wait on any implicit rendering fences */ - ret = dma_resv_wait_timeout_rcu(resv, write, true, - MAX_SCHEDULE_TIMEOUT); + ret = dma_resv_wait_timeout_unlocked(resv, write, true, +MAX_SCHEDULE_TIMEOUT); if (ret < 0) return ret; diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c index 6ddbeb5dfbf65..d6f1ed4cd4d55 100644 --- a/drivers/dma-buf/dma-resv.c +++ b/drivers/dma-buf/dma-resv.c @@ -417,7 +417,7 @@ int dma_resv_copy_fences(struct dma_resv *dst, struct dma_resv *src) EXPORT_SYMBOL(dma_resv_copy_fences); /** - * dma_resv_get_fences_rcu - Get an object's shared and exclusive + * dma_resv_get_fences_unlocked - Get an object's shared and exclusive * fences without update side lock held * @obj: the reservation object * @pfence_excl: the returned exclusive fence (or NULL) @@ -429,10 +429,10 @@ EXPORT_SYMBOL(dma_resv_copy_fences); * exclusive fence is not specified the fence is put into the array of the * shared fences
Re: [Intel-gfx] [PATCH 2/7] dma-buf: Rename dma_resv helpers from _rcu to _unlocked (v2)
On Wed, May 26, 2021 at 12:57:40PM +0200, Christian König wrote: > Am 25.05.21 um 23:17 schrieb Jason Ekstrand: > > None of these helpers actually leak any RCU details to the caller. They > > all assume you have a genuine reference, take the RCU read lock, and > > retry if needed. Naming them with an _rcu is likely to cause callers > > more panic than needed. > > I'm really wondering if we need this postfix in the first place. > > If we use the right rcu_dereference_check() macro then those functions can > be called with both the reservation object locked and unlocked. It shouldn't > matter to them. > > But getting rid of the _rcu postfix sounds like a good idea in general to > me. So does that count as an ack or not? If yes I think we should land this patch right away, since it's going to conflict real fast badly. -Daniel > > Christian. > > > > > v2 (Jason Ekstrand): > > - Fix function argument indentation > > > > Signed-off-by: Jason Ekstrand > > Suggested-by: Daniel Vetter > > Cc: Christian König > > Cc: Maarten Lankhorst > > Cc: Maxime Ripard > > Cc: Thomas Zimmermann > > Cc: Lucas Stach > > Cc: Rob Clark > > Cc: Sean Paul > > Cc: Huang Rui > > Cc: Gerd Hoffmann > > Cc: VMware Graphics > > --- > > drivers/dma-buf/dma-buf.c | 4 +-- > > drivers/dma-buf/dma-resv.c| 28 +-- > > drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++-- > > drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +- > > drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4 +-- > > drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 6 ++-- > > drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c| 4 +-- > > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 4 +-- > > drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 6 ++-- > > drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 14 +- > > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 ++-- > > drivers/gpu/drm/drm_gem.c | 10 +++ > > drivers/gpu/drm/drm_gem_atomic_helper.c | 2 +- > > drivers/gpu/drm/etnaviv/etnaviv_gem.c | 7 ++--- > > drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 8 +++--- > > drivers/gpu/drm/i915/display/intel_display.c | 2 +- > > drivers/gpu/drm/i915/dma_resv_utils.c | 2 +- > > drivers/gpu/drm/i915/gem/i915_gem_busy.c | 2 +- > > .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +- > > drivers/gpu/drm/i915/gem/i915_gem_object.h| 2 +- > > drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 4 +-- > > drivers/gpu/drm/i915/gem/i915_gem_wait.c | 10 +++ > > drivers/gpu/drm/i915/i915_request.c | 6 ++-- > > drivers/gpu/drm/i915/i915_sw_fence.c | 4 +-- > > drivers/gpu/drm/msm/msm_gem.c | 3 +- > > drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +- > > drivers/gpu/drm/nouveau/nouveau_gem.c | 4 +-- > > drivers/gpu/drm/panfrost/panfrost_drv.c | 4 +-- > > drivers/gpu/drm/panfrost/panfrost_job.c | 2 +- > > drivers/gpu/drm/radeon/radeon_gem.c | 6 ++-- > > drivers/gpu/drm/radeon/radeon_mn.c| 4 +-- > > drivers/gpu/drm/ttm/ttm_bo.c | 18 ++-- > > drivers/gpu/drm/vgem/vgem_fence.c | 4 +-- > > drivers/gpu/drm/virtio/virtgpu_ioctl.c| 6 ++-- > > drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 2 +- > > include/linux/dma-resv.h | 18 ++-- > > 36 files changed, 108 insertions(+), 110 deletions(-) > > > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > > index f264b70c383eb..ed6451d55d663 100644 > > --- a/drivers/dma-buf/dma-buf.c > > +++ b/drivers/dma-buf/dma-buf.c > > @@ -1147,8 +1147,8 @@ static int __dma_buf_begin_cpu_access(struct dma_buf > > *dmabuf, > > long ret; > > /* Wait on any implicit rendering fences */ > > - ret = dma_resv_wait_timeout_rcu(resv, write, true, > > - MAX_SCHEDULE_TIMEOUT); > > + ret = dma_resv_wait_timeout_unlocked(resv, write, true, > > +MAX_SCHEDULE_TIMEOUT); > > if (ret < 0) > > return ret; > > diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c > > index 6ddbeb5dfbf65..d6f1ed4cd4d55 100644 > > --- a/drivers/dma-buf/dma-resv.c > > +++ b/drivers/dma-buf/dma-resv.c > > @@ -417,7 +417,7 @@ int dma_resv_copy_fences(struct dma_resv *dst, struct > > dma_resv *src) > > EXPORT_SYMBOL(dma_resv_copy_fences); > > /** > > - * dma_resv_get_fences_rcu - Get an object's shared and exclusive > > + * dma_resv_get_fences_unlocked - Get an object's shared and exclusive > >* fences without update side lock held > >* @obj: the reservation object > >* @pfence_excl: the returned exclusive fence (or NULL) > > @@ -429,10 +429,10 @@ EXPORT_SYMBOL(dma_resv_copy_fences); > >* exclusive fence is not specified the fence is put into the array of the
Re: [Intel-gfx] [PATCH 2/7] dma-buf: Rename dma_resv helpers from _rcu to _unlocked (v2)
Am 25.05.21 um 23:17 schrieb Jason Ekstrand:
None of these helpers actually leak any RCU details to the caller. They
all assume you have a genuine reference, take the RCU read lock, and
retry if needed. Naming them with an _rcu is likely to cause callers
more panic than needed.
I'm really wondering if we need this postfix in the first place.
If we use the right rcu_dereference_check() macro then those functions
can be called with both the reservation object locked and unlocked. It
shouldn't matter to them.
But getting rid of the _rcu postfix sounds like a good idea in general
to me.
Christian.
v2 (Jason Ekstrand):
- Fix function argument indentation
Signed-off-by: Jason Ekstrand
Suggested-by: Daniel Vetter
Cc: Christian König
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: Lucas Stach
Cc: Rob Clark
Cc: Sean Paul
Cc: Huang Rui
Cc: Gerd Hoffmann
Cc: VMware Graphics
---
drivers/dma-buf/dma-buf.c | 4 +--
drivers/dma-buf/dma-resv.c| 28 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 6 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c| 4 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 4 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 6 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 14 +-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 ++--
drivers/gpu/drm/drm_gem.c | 10 +++
drivers/gpu/drm/drm_gem_atomic_helper.c | 2 +-
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 7 ++---
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 8 +++---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/dma_resv_utils.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_busy.c | 2 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_object.h| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 4 +--
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 10 +++
drivers/gpu/drm/i915/i915_request.c | 6 ++--
drivers/gpu/drm/i915/i915_sw_fence.c | 4 +--
drivers/gpu/drm/msm/msm_gem.c | 3 +-
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 4 +--
drivers/gpu/drm/panfrost/panfrost_drv.c | 4 +--
drivers/gpu/drm/panfrost/panfrost_job.c | 2 +-
drivers/gpu/drm/radeon/radeon_gem.c | 6 ++--
drivers/gpu/drm/radeon/radeon_mn.c| 4 +--
drivers/gpu/drm/ttm/ttm_bo.c | 18 ++--
drivers/gpu/drm/vgem/vgem_fence.c | 4 +--
drivers/gpu/drm/virtio/virtgpu_ioctl.c| 6 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 2 +-
include/linux/dma-resv.h | 18 ++--
36 files changed, 108 insertions(+), 110 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index f264b70c383eb..ed6451d55d663 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1147,8 +1147,8 @@ static int __dma_buf_begin_cpu_access(struct dma_buf
*dmabuf,
long ret;
/* Wait on any implicit rendering fences */
- ret = dma_resv_wait_timeout_rcu(resv, write, true,
- MAX_SCHEDULE_TIMEOUT);
+ ret = dma_resv_wait_timeout_unlocked(resv, write, true,
+MAX_SCHEDULE_TIMEOUT);
if (ret < 0)
return ret;
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 6ddbeb5dfbf65..d6f1ed4cd4d55 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -417,7 +417,7 @@ int dma_resv_copy_fences(struct dma_resv *dst, struct
dma_resv *src)
EXPORT_SYMBOL(dma_resv_copy_fences);
/**
- * dma_resv_get_fences_rcu - Get an object's shared and exclusive
+ * dma_resv_get_fences_unlocked - Get an object's shared and exclusive
* fences without update side lock held
* @obj: the reservation object
* @pfence_excl: the returned exclusive fence (or NULL)
@@ -429,10 +429,10 @@ EXPORT_SYMBOL(dma_resv_copy_fences);
* exclusive fence is not specified the fence is put into the array of the
* shared fences as well. Returns either zero or -ENOMEM.
*/
-int dma_resv_get_fences_rcu(struct dma_resv *obj,
- struct dma_fence **pfence_excl,
- unsigned *pshared_count,
- struct dma_fence ***pshared)
+int dma_resv_get_fences_unlocked(struct dma_resv *obj,
+struct dma_fence **pfence_excl,
+unsigned *pshared_count,
+struct dma_fence ***pshared)
{
[Intel-gfx] [PATCH 2/7] dma-buf: Rename dma_resv helpers from _rcu to _unlocked (v2)
None of these helpers actually leak any RCU details to the caller. They
all assume you have a genuine reference, take the RCU read lock, and
retry if needed. Naming them with an _rcu is likely to cause callers
more panic than needed.
v2 (Jason Ekstrand):
- Fix function argument indentation
Signed-off-by: Jason Ekstrand
Suggested-by: Daniel Vetter
Cc: Christian König
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: Lucas Stach
Cc: Rob Clark
Cc: Sean Paul
Cc: Huang Rui
Cc: Gerd Hoffmann
Cc: VMware Graphics
---
drivers/dma-buf/dma-buf.c | 4 +--
drivers/dma-buf/dma-resv.c| 28 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 6 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c| 4 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 4 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 6 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 14 +-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 ++--
drivers/gpu/drm/drm_gem.c | 10 +++
drivers/gpu/drm/drm_gem_atomic_helper.c | 2 +-
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 7 ++---
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 8 +++---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/dma_resv_utils.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_busy.c | 2 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_object.h| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 4 +--
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 10 +++
drivers/gpu/drm/i915/i915_request.c | 6 ++--
drivers/gpu/drm/i915/i915_sw_fence.c | 4 +--
drivers/gpu/drm/msm/msm_gem.c | 3 +-
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 4 +--
drivers/gpu/drm/panfrost/panfrost_drv.c | 4 +--
drivers/gpu/drm/panfrost/panfrost_job.c | 2 +-
drivers/gpu/drm/radeon/radeon_gem.c | 6 ++--
drivers/gpu/drm/radeon/radeon_mn.c| 4 +--
drivers/gpu/drm/ttm/ttm_bo.c | 18 ++--
drivers/gpu/drm/vgem/vgem_fence.c | 4 +--
drivers/gpu/drm/virtio/virtgpu_ioctl.c| 6 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 2 +-
include/linux/dma-resv.h | 18 ++--
36 files changed, 108 insertions(+), 110 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index f264b70c383eb..ed6451d55d663 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1147,8 +1147,8 @@ static int __dma_buf_begin_cpu_access(struct dma_buf
*dmabuf,
long ret;
/* Wait on any implicit rendering fences */
- ret = dma_resv_wait_timeout_rcu(resv, write, true,
- MAX_SCHEDULE_TIMEOUT);
+ ret = dma_resv_wait_timeout_unlocked(resv, write, true,
+MAX_SCHEDULE_TIMEOUT);
if (ret < 0)
return ret;
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 6ddbeb5dfbf65..d6f1ed4cd4d55 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -417,7 +417,7 @@ int dma_resv_copy_fences(struct dma_resv *dst, struct
dma_resv *src)
EXPORT_SYMBOL(dma_resv_copy_fences);
/**
- * dma_resv_get_fences_rcu - Get an object's shared and exclusive
+ * dma_resv_get_fences_unlocked - Get an object's shared and exclusive
* fences without update side lock held
* @obj: the reservation object
* @pfence_excl: the returned exclusive fence (or NULL)
@@ -429,10 +429,10 @@ EXPORT_SYMBOL(dma_resv_copy_fences);
* exclusive fence is not specified the fence is put into the array of the
* shared fences as well. Returns either zero or -ENOMEM.
*/
-int dma_resv_get_fences_rcu(struct dma_resv *obj,
- struct dma_fence **pfence_excl,
- unsigned *pshared_count,
- struct dma_fence ***pshared)
+int dma_resv_get_fences_unlocked(struct dma_resv *obj,
+struct dma_fence **pfence_excl,
+unsigned *pshared_count,
+struct dma_fence ***pshared)
{
struct dma_fence **shared = NULL;
struct dma_fence *fence_excl;
@@ -515,10 +515,10 @@ int dma_resv_get_fences_rcu(struct dma_resv *obj,
*pshared = shared;
return ret;
}
-EXPORT_SYMBOL_GPL(dma_resv_get_fences_rcu);
+EXPORT_SYMBOL_GPL(dma_resv_get_fences_unlocked);
/**
- * dma_resv_wait_timeout_rcu - Wait on reservation's objects
+ * dma_resv_wait_timeout_unlocked - Wait on reservation's objects
*
