All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: DRI Development <dri-devel@lists.freedesktop.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: [PATCH RESEND 10/20] drm/gma500: Drop dev->struct_mutex from mmap offset function
Date: Thu, 19 Nov 2015 17:46:39 +0100	[thread overview]
Message-ID: <1447951610-12622-11-git-send-email-daniel.vetter@ffwll.ch> (raw)
In-Reply-To: <1447951610-12622-1-git-send-email-daniel.vetter@ffwll.ch>

Simply forgotten about this when I was doing my general cleansing of
simple gem mmap offset functions. There's nothing but core functions
called here, and they all have their own protection already.

Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/gma500/gem.c | 13 +++----------
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
index e3bdc8b1c32c..f0357f525f56 100644
--- a/drivers/gpu/drm/gma500/gem.c
+++ b/drivers/gpu/drm/gma500/gem.c
@@ -62,15 +62,10 @@ int psb_gem_dumb_map_gtt(struct drm_file *file, struct drm_device *dev,
 	int ret = 0;
 	struct drm_gem_object *obj;
 
-	mutex_lock(&dev->struct_mutex);
-
 	/* GEM does all our handle to object mapping */
 	obj = drm_gem_object_lookup(dev, file, handle);
-	if (obj == NULL) {
-		ret = -ENOENT;
-		goto unlock;
-	}
-	/* What validation is needed here ? */
+	if (obj == NULL)
+		return -ENOENT;
 
 	/* Make it mmapable */
 	ret = drm_gem_create_mmap_offset(obj);
@@ -78,9 +73,7 @@ int psb_gem_dumb_map_gtt(struct drm_file *file, struct drm_device *dev,
 		goto out;
 	*offset = drm_vma_node_offset_addr(&obj->vma_node);
 out:
-	drm_gem_object_unreference(obj);
-unlock:
-	mutex_unlock(&dev->struct_mutex);
+	drm_gem_object_unreference_unlocked(obj);
 	return ret;
 }
 
-- 
2.5.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2015-11-19 16:46 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-19 16:46 [PATCH RESEND 00/20] dev->struct_mutex locking crusade Daniel Vetter
2015-11-19 16:46 ` [PATCH RESEND 01/20] drm/armada: Plug leak in dumb_map_offset Daniel Vetter
2015-11-19 16:46 ` [PATCH RESEND 02/20] drm/armada: Don't grab dev->struct_mutex for in mmap offset ioctl Daniel Vetter
2015-11-19 16:46 ` [PATCH RESEND 03/20] drm/armada: Drop struct_mutex from cursor paths Daniel Vetter
2015-11-19 16:46 ` [PATCH RESEND 04/20] drm/armada: Use a private mutex to protect priv->linear Daniel Vetter
2015-11-19 16:46 ` [PATCH RESEND 05/20] drm/tegra: don't take dev->struct_mutex in mmap offset ioctl Daniel Vetter
2015-11-19 16:46 ` [PATCH RESEND 06/20] drm/tegra: Use drm_gem_object_unreference_unlocked Daniel Vetter
2015-11-19 16:46 ` [PATCH RESEND 07/20] drm/gma500: Use correct unref in the gem bo create function Daniel Vetter
2015-11-19 16:46 ` [PATCH RESEND 08/20] drm/gma500: Drop dev->struct_mutex from modeset code Daniel Vetter
2015-11-19 16:46 ` [PATCH RESEND 09/20] drm/gma500: Drop dev->struct_mutex from fbdev init/teardown code Daniel Vetter
2015-11-19 16:46 ` Daniel Vetter [this message]
2015-11-19 16:46 ` [PATCH RESEND 11/20] drm/gma500: Add driver private mutex for the fault handler Daniel Vetter
2015-11-19 16:46 ` [PATCH RESEND 12/20] drm/nouveau: Drop dev->struct_mutex from fbdev init Daniel Vetter
2015-11-19 16:46 ` [PATCH RESEND 13/20] drm/exynos: Drop dev->struct_mutex from mmap offset function Daniel Vetter
2015-11-19 16:46 ` [PATCH RESEND 14/20] drm/exynos: drop struct_mutex from exynos_gem_map_sgt_with_dma Daniel Vetter
2015-11-19 16:46 ` [PATCH RESEND 15/20] drm/exynos: drop struct_mutex from exynos_drm_gem_get_ioctl Daniel Vetter
2015-11-19 16:50   ` Daniel Stone
2015-11-19 16:59     ` Daniel Vetter
2015-11-19 16:46 ` [PATCH RESEND 16/20] drm/exynos: drop struct_mutex from fbdev setup Daniel Vetter
2015-11-19 16:46 ` [PATCH RESEND 17/20] drm/vgem: Simplify dum_map Daniel Vetter
2015-11-19 16:46 ` [PATCH RESEND 18/20] drm/vgem: Move get_pages to gem_create Daniel Vetter
2015-11-19 16:46 ` [PATCH RESEND 19/20] drm/vgem: Drop dev->struct_mutex Daniel Vetter
2015-11-19 16:46 ` [PATCH RESEND 20/20] drm/vma_manage: Drop has_offset Daniel Vetter
2015-11-19 16:46 ` [PATCH] drm/sysfs: Send out uevent when connector->force changes Daniel Vetter
2015-11-19 21:06   ` Chris Wilson
2015-11-20  8:11     ` Daniel Vetter
2015-11-20  9:25       ` Chris Wilson
2015-11-24 10:51         ` Daniel Vetter
2015-11-24 11:46           ` Chris Wilson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1447951610-12622-11-git-send-email-daniel.vetter@ffwll.ch \
    --to=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.