| Message ID | 1480335612-12069-2-git-send-email-nhaehnle@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Op 28-11-16 om 13:20 schreef Nicolai Hähnle: > From: Nicolai Hähnle <Nicolai.Haehnle@amd.com> > > Cc: Peter Zijlstra <peterz@infradead.org> > Cc: Ingo Molnar <mingo@redhat.com> > Cc: Maarten Lankhorst <dev@mblankhorst.nl> > Cc: Daniel Vetter <daniel@ffwll.ch> > Cc: Chris Wilson <chris@chris-wilson.co.uk> > Cc: dri-devel@lists.freedesktop.org > Signed-off-by: Nicolai Hähnle <Nicolai.Haehnle@amd.com> > --- > drivers/gpu/drm/vgem/vgem_fence.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/vgem/vgem_fence.c b/drivers/gpu/drm/vgem/vgem_fence.c > index 488909a..e1d516f 100644 > --- a/drivers/gpu/drm/vgem/vgem_fence.c > +++ b/drivers/gpu/drm/vgem/vgem_fence.c > @@ -191,12 +191,12 @@ int vgem_fence_attach_ioctl(struct drm_device *dev, > > /* Expose the fence via the dma-buf */ > ret = 0; > - mutex_lock(&resv->lock.base); > + ww_mutex_lock(&resv->lock.base, NULL); Yuck, can we rename base to __NEVER_TOUCH_DIRECTLY_OUTSIDE_LOCKING_CORE? It's harder to get them confused like that, even with a null context it's illegal to call mutex_lock/unlock directly. ~Maarten
On Mon, Nov 28, 2016 at 01:42:26PM +0100, Maarten Lankhorst wrote: > > + ww_mutex_lock(&resv->lock.base, NULL); > Yuck, can we rename base to __NEVER_TOUCH_DIRECTLY_OUTSIDE_LOCKING_CORE? > It's harder to get them confused like that, even with a null context it's illegal to call mutex_lock/unlock directly. I think there's a __private sparse annotation that could be used.
Am 28.11.2016 um 13:20 schrieb Nicolai Hähnle: > From: Nicolai Hähnle <Nicolai.Haehnle@amd.com> > > Cc: Peter Zijlstra <peterz@infradead.org> > Cc: Ingo Molnar <mingo@redhat.com> > Cc: Maarten Lankhorst <dev@mblankhorst.nl> > Cc: Daniel Vetter <daniel@ffwll.ch> > Cc: Chris Wilson <chris@chris-wilson.co.uk> > Cc: dri-devel@lists.freedesktop.org > Signed-off-by: Nicolai Hähnle <Nicolai.Haehnle@amd.com> > --- > drivers/gpu/drm/vgem/vgem_fence.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/vgem/vgem_fence.c b/drivers/gpu/drm/vgem/vgem_fence.c > index 488909a..e1d516f 100644 > --- a/drivers/gpu/drm/vgem/vgem_fence.c > +++ b/drivers/gpu/drm/vgem/vgem_fence.c > @@ -191,12 +191,12 @@ int vgem_fence_attach_ioctl(struct drm_device *dev, > > /* Expose the fence via the dma-buf */ > ret = 0; > - mutex_lock(&resv->lock.base); > + ww_mutex_lock(&resv->lock.base, NULL); Accessing the base member here is probably superfluous now and will most likely raise a warning. Christian. > if (arg->flags & VGEM_FENCE_WRITE) > reservation_object_add_excl_fence(resv, fence); > else if ((ret = reservation_object_reserve_shared(resv)) == 0) > reservation_object_add_shared_fence(resv, fence); > - mutex_unlock(&resv->lock.base); > + ww_mutex_unlock(&resv->lock.base); > > /* Record the fence in our idr for later signaling */ > if (ret == 0) {
diff --git a/drivers/gpu/drm/vgem/vgem_fence.c b/drivers/gpu/drm/vgem/vgem_fence.c index 488909a..e1d516f 100644 --- a/drivers/gpu/drm/vgem/vgem_fence.c +++ b/drivers/gpu/drm/vgem/vgem_fence.c @@ -191,12 +191,12 @@ int vgem_fence_attach_ioctl(struct drm_device *dev, /* Expose the fence via the dma-buf */ ret = 0; - mutex_lock(&resv->lock.base); + ww_mutex_lock(&resv->lock.base, NULL); if (arg->flags & VGEM_FENCE_WRITE) reservation_object_add_excl_fence(resv, fence); else if ((ret = reservation_object_reserve_shared(resv)) == 0) reservation_object_add_shared_fence(resv, fence); - mutex_unlock(&resv->lock.base); + ww_mutex_unlock(&resv->lock.base); /* Record the fence in our idr for later signaling */ if (ret == 0) {