All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: krh@bitplanet.net
Cc: eric@anholt.net, "Wang Chen" <wangchen@cn.fujitsu.com>,
	dri-devel@lists.sf.net, linux-kernel@vger.kernel.org,
	"Kristian Høgsberg" <krh@redhat.com>,
	"Nick Piggin" <npiggin@suse.de>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Hugh Dickins" <hugh@veritas.com>
Subject: Re: [PATCH] drm: Take mmap_sem up front to avoid lock order violations.
Date: Thu, 19 Feb 2009 10:19:05 +0100	[thread overview]
Message-ID: <1235035145.4612.38.camel@laptop> (raw)
In-Reply-To: <1234975113-4941-1-git-send-email-krh@bitplanet.net>

On Wed, 2009-02-18 at 11:38 -0500, krh@bitplanet.net wrote:
> From: Kristian Høgsberg <krh@redhat.com>
> 
> A number of GEM operations (and legacy drm ones) want to copy data to
> or from userspace while holding the struct_mutex lock.  However, the
> fault handler calls us with the mmap_sem held and thus enforces the
> opposite locking order.  This patch downs the mmap_sem up front for
> those operations that access userspace data under the struct_mutex
> lock to ensure the locking order is consistent.
> 
> Signed-off-by: Kristian Høgsberg <krh@redhat.com>
> ---
> 
> Here's a different and simpler attempt to fix the locking order
> problem.  We can just down_read() the mmap_sem pre-emptively up-front,
> and the locking order is respected.  It's simpler than the
> mutex_trylock() game, avoids introducing a new mutex.
> 

Hell no!

for one, mmap_sem is not a recursive lock, so a pagefault will utterly
fail with this in place.

Secondly, holding mmap_sem for no good reason just sucks.

>  drivers/gpu/drm/i915/i915_dma.c |    6 +++++-
>  drivers/gpu/drm/i915/i915_gem.c |   20 +++++++++++++-------
>  2 files changed, 18 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 81f1cff..d8b58d9 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -642,9 +642,11 @@ static int i915_batchbuffer(struct drm_device *dev, void *data,
>  						       sizeof(struct drm_clip_rect)))
>  		return -EFAULT;
>  
> +	down_read(&current->mm->mmap_sem);
>  	mutex_lock(&dev->struct_mutex);
>  	ret = i915_dispatch_batchbuffer(dev, batch);
>  	mutex_unlock(&dev->struct_mutex);
> +	up_read(&current->mm->mmap_sem);
>  
>  	if (sarea_priv)
>  		sarea_priv->last_dispatch = READ_BREADCRUMB(dev_priv);
> @@ -674,14 +676,16 @@ static int i915_cmdbuffer(struct drm_device *dev, void *data,
>  		return -EFAULT;
>  	}
>  
> +	down_read(&current->mm->mmap_sem);
>  	mutex_lock(&dev->struct_mutex);
>  	ret = i915_dispatch_cmdbuffer(dev, cmdbuf);
>  	mutex_unlock(&dev->struct_mutex);
> +	up_read(&current->mm->mmap_sem);
> +
>  	if (ret) {
>  		DRM_ERROR("i915_dispatch_cmdbuffer failed\n");
>  		return ret;
>  	}
> -
>  	if (sarea_priv)
>  		sarea_priv->last_dispatch = READ_BREADCRUMB(dev_priv);
>  	return 0;
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index d9cd42f..3dd8b6e 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -171,6 +171,7 @@ i915_gem_pread_ioctl(struct drm_device *dev, void *data,
>  		return -EINVAL;
>  	}
>  
> +	down_read(&current->mm->mmap_sem);
>  	mutex_lock(&dev->struct_mutex);
>  
>  	ret = i915_gem_object_set_cpu_read_domain_range(obj, args->offset,
> @@ -196,6 +197,7 @@ i915_gem_pread_ioctl(struct drm_device *dev, void *data,
>  
>  	drm_gem_object_unreference(obj);
>  	mutex_unlock(&dev->struct_mutex);
> +	up_read(&current->mm->mmap_sem);
>  
>  	return 0;
>  }
> @@ -264,7 +266,7 @@ i915_gem_gtt_pwrite(struct drm_device *dev, struct drm_gem_object *obj,
>  	if (!access_ok(VERIFY_READ, user_data, remain))
>  		return -EFAULT;
>  
> -
> +	down_read(&current->mm->mmap_sem);
>  	mutex_lock(&dev->struct_mutex);
>  	ret = i915_gem_object_pin(obj, 0);
>  	if (ret) {
> @@ -315,6 +317,7 @@ i915_gem_gtt_pwrite(struct drm_device *dev, struct drm_gem_object *obj,
>  fail:
>  	i915_gem_object_unpin(obj);
>  	mutex_unlock(&dev->struct_mutex);
> +	up_read(&current->mm->mmap_sem);
>  
>  	return ret;
>  }
> @@ -328,6 +331,7 @@ i915_gem_shmem_pwrite(struct drm_device *dev, struct drm_gem_object *obj,
>  	loff_t offset;
>  	ssize_t written;
>  
> +	down_read(&current->mm->mmap_sem);
>  	mutex_lock(&dev->struct_mutex);
>  
>  	ret = i915_gem_object_set_to_cpu_domain(obj, 1);
> @@ -350,6 +354,7 @@ i915_gem_shmem_pwrite(struct drm_device *dev, struct drm_gem_object *obj,
>  	}
>  
>  	mutex_unlock(&dev->struct_mutex);
> +	up_read(&current->mm->mmap_sem);
>  
>  	return 0;
>  }
> @@ -2473,22 +2478,21 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
>  		goto pre_mutex_err;
>  	}
>  
> +	down_read(&current->mm->mmap_sem);
>  	mutex_lock(&dev->struct_mutex);
>  
>  	i915_verify_inactive(dev, __FILE__, __LINE__);
>  
>  	if (dev_priv->mm.wedged) {
>  		DRM_ERROR("Execbuf while wedged\n");
> -		mutex_unlock(&dev->struct_mutex);
>  		ret = -EIO;
> -		goto pre_mutex_err;
> +		goto mutex_err;
>  	}
>  
>  	if (dev_priv->mm.suspended) {
>  		DRM_ERROR("Execbuf while VT-switched.\n");
> -		mutex_unlock(&dev->struct_mutex);
>  		ret = -EBUSY;
> -		goto pre_mutex_err;
> +		goto mutex_err;
>  	}
>  
>  	/* Look up object handles */
> @@ -2641,8 +2645,6 @@ err:
>  	for (i = 0; i < args->buffer_count; i++)
>  		drm_gem_object_unreference(object_list[i]);
>  
> -	mutex_unlock(&dev->struct_mutex);
> -
>  	if (!ret) {
>  		/* Copy the new buffer offsets back to the user's exec list. */
>  		ret = copy_to_user((struct drm_i915_relocation_entry __user *)
> @@ -2655,6 +2657,10 @@ err:
>  				  args->buffer_count, ret);
>  	}
>  
> +mutex_err:
> +	mutex_unlock(&dev->struct_mutex);
> +	up_read(&current->mm->mmap_sem);
> +
>  pre_mutex_err:
>  	drm_free(object_list, sizeof(*object_list) * args->buffer_count,
>  		 DRM_MEM_DRIVER);


  reply	other threads:[~2009-02-19  9:19 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-18  0:59 [PATCH] drm: Fix lock order reversal between mmap_sem and struct_mutex Eric Anholt
2009-02-18  8:02 ` Wang Chen
2009-02-18 16:38   ` [PATCH] drm: Take mmap_sem up front to avoid lock order violations krh
2009-02-19  9:19     ` Peter Zijlstra [this message]
2009-02-19 10:33       ` Peter Zijlstra
2009-02-19 14:49         ` Kristian Høgsberg
2009-02-19 15:17           ` Nick Piggin
2009-02-19 15:21             ` Kristian Høgsberg
2009-02-19 12:57       ` Nick Piggin
2009-02-21  2:33         ` Eric Anholt
2009-02-18 15:08 ` [PATCH] drm: Fix lock order reversal between mmap_sem and struct_mutex Peter Zijlstra
2009-02-19 21:02   ` Thomas Hellstrom
2009-02-19 22:26     ` Peter Zijlstra
2009-02-20  2:04       ` Eric Anholt
2009-02-20  7:36         ` Peter Zijlstra
2009-02-25  8:15           ` Eric Anholt
2009-02-25  8:54             ` Thomas Hellström
2009-02-25  9:07             ` Peter Zijlstra
2009-02-20  8:31       ` Thomas Hellstrom
2009-02-20  8:47         ` Peter Zijlstra

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=1235035145.4612.38.camel@laptop \
    --to=peterz@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=dri-devel@lists.sf.net \
    --cc=eric@anholt.net \
    --cc=hugh@veritas.com \
    --cc=krh@bitplanet.net \
    --cc=krh@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=npiggin@suse.de \
    --cc=wangchen@cn.fujitsu.com \
    /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.