All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@mellanox.com>
To: Christoph Hellwig <hch@lst.de>
Cc: "Jérôme Glisse" <jglisse@redhat.com>,
	"Ben Skeggs" <bskeggs@redhat.com>,
	"Ralph Campbell" <rcampbell@nvidia.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"nouveau@lists.freedesktop.org" <nouveau@lists.freedesktop.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4/6] nouveau: unlock mmap_sem on all errors from nouveau_range_fault
Date: Tue, 23 Jul 2019 15:18:28 +0000	[thread overview]
Message-ID: <20190723151824.GL15331@mellanox.com> (raw)
In-Reply-To: <20190722094426.18563-5-hch@lst.de>

On Mon, Jul 22, 2019 at 11:44:24AM +0200, Christoph Hellwig wrote:
> Currently nouveau_svm_fault expects nouveau_range_fault to never unlock
> mmap_sem, but the latter unlocks it for a random selection of error
> codes. Fix this up by always unlocking mmap_sem for non-zero return
> values in nouveau_range_fault, and only unlocking it in the caller
> for successful returns.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
>  drivers/gpu/drm/nouveau/nouveau_svm.c | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c b/drivers/gpu/drm/nouveau/nouveau_svm.c
> index 5dd83a46578f..5de2d54b9782 100644
> +++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
> @@ -494,8 +494,10 @@ nouveau_range_fault(struct hmm_mirror *mirror, struct hmm_range *range)
>  	ret = hmm_range_register(range, mirror,
>  				 range->start, range->end,
>  				 PAGE_SHIFT);
> -	if (ret)
> +	if (ret) {
> +		up_read(&range->vma->vm_mm->mmap_sem);
>  		return (int)ret;
> +	}
>  
>  	if (!hmm_range_wait_until_valid(range, HMM_RANGE_DEFAULT_TIMEOUT)) {
>  		up_read(&range->vma->vm_mm->mmap_sem);
> @@ -504,11 +506,9 @@ nouveau_range_fault(struct hmm_mirror *mirror, struct hmm_range *range)
>  
>  	ret = hmm_range_fault(range, true);
>  	if (ret <= 0) {
> -		if (ret == -EBUSY || !ret) {
> -			up_read(&range->vma->vm_mm->mmap_sem);
> -			ret = -EBUSY;
> -		} else if (ret == -EAGAIN)
> +		if (ret == 0)
>  			ret = -EBUSY;
> +		up_read(&range->vma->vm_mm->mmap_sem);
>  		hmm_range_unregister(range);
>  		return ret;

Hum..

The caller does this:

again:
		ret = nouveau_range_fault(&svmm->mirror, &range);
		if (ret == 0) {
			mutex_lock(&svmm->mutex);
			if (!nouveau_range_done(&range)) {
				mutex_unlock(&svmm->mutex);
				goto again;

And we can't call nouveau_range_fault() -> hmm_range_fault() without
holding the mmap_sem, so we can't allow nouveau_range_fault to unlock
it.

Maybe this instead? 

diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c b/drivers/gpu/drm/nouveau/nouveau_svm.c
index a9c5c58d425b3d..92cf760a9bcc5d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_svm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
@@ -494,21 +494,16 @@ nouveau_range_fault(struct hmm_mirror *mirror, struct hmm_range *range)
 	ret = hmm_range_register(range, mirror,
 				 range->start, range->end,
 				 PAGE_SHIFT);
-	if (ret) {
-		up_read(&range->vma->vm_mm->mmap_sem);
+	if (ret)
 		return (int)ret;
-	}
 
-	if (!hmm_range_wait_until_valid(range, HMM_RANGE_DEFAULT_TIMEOUT)) {
-		up_read(&range->vma->vm_mm->mmap_sem);
+	if (!hmm_range_wait_until_valid(range, HMM_RANGE_DEFAULT_TIMEOUT))
 		return -EBUSY;
-	}
 
 	ret = hmm_range_fault(range, true);
 	if (ret <= 0) {
 		if (ret == 0)
 			ret = -EBUSY;
-		up_read(&range->vma->vm_mm->mmap_sem);
 		hmm_range_unregister(range);
 		return ret;
 	}
@@ -706,8 +701,8 @@ nouveau_svm_fault(struct nvif_notify *notify)
 						NULL);
 			svmm->vmm->vmm.object.client->super = false;
 			mutex_unlock(&svmm->mutex);
-			up_read(&svmm->mm->mmap_sem);
 		}
+		up_read(&svmm->mm->mmap_sem);
 
 		/* Cancel any faults in the window whose pages didn't manage
 		 * to keep their valid bit, or stay writeable when required.

  reply	other threads:[~2019-07-23 15:18 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-22  9:44 hmm_range_fault related fixes and legacy API removal v2 Christoph Hellwig
2019-07-22  9:44 ` [PATCH 1/6] mm: always return EBUSY for invalid ranges in hmm_range_{fault,snapshot} Christoph Hellwig
2019-07-22  9:44   ` [PATCH 1/6] mm: always return EBUSY for invalid ranges in hmm_range_{fault, snapshot} Christoph Hellwig
2019-07-22 14:37   ` [PATCH 1/6] mm: always return EBUSY for invalid ranges in hmm_range_{fault,snapshot} Souptick Joarder
2019-07-22 14:37     ` [PATCH 1/6] mm: always return EBUSY for invalid ranges in hmm_range_{fault, snapshot} Souptick Joarder
2019-07-23 14:54     ` [PATCH 1/6] mm: always return EBUSY for invalid ranges in hmm_range_{fault,snapshot} Jason Gunthorpe
2019-07-23 16:19       ` Christoph Hellwig
2019-07-23 16:19         ` [PATCH 1/6] mm: always return EBUSY for invalid ranges in hmm_range_{fault, snapshot} Christoph Hellwig
2019-07-23 17:18         ` [PATCH 1/6] mm: always return EBUSY for invalid ranges in hmm_range_{fault,snapshot} Jason Gunthorpe
2019-07-22  9:44 ` [PATCH 2/6] mm: move hmm_vma_range_done and hmm_vma_fault to nouveau Christoph Hellwig
2019-07-23 14:55   ` Jason Gunthorpe
2019-07-22  9:44 ` [PATCH 3/6] nouveau: remove the block parameter to nouveau_range_fault Christoph Hellwig
2019-07-23 14:56   ` Jason Gunthorpe
2019-07-23 14:56     ` Jason Gunthorpe
2019-07-23 16:23     ` Christoph Hellwig
2019-07-22  9:44 ` [PATCH 4/6] nouveau: unlock mmap_sem on all errors from nouveau_range_fault Christoph Hellwig
2019-07-23 15:18   ` Jason Gunthorpe [this message]
2019-07-23 16:30     ` Christoph Hellwig
2019-07-23 17:17       ` Jason Gunthorpe
2019-07-23 17:23         ` Christoph Hellwig
2019-07-23 17:30           ` Jason Gunthorpe
2019-07-22  9:44 ` [PATCH 5/6] nouveau: return -EBUSY when hmm_range_wait_until_valid fails Christoph Hellwig
2019-07-23 15:18   ` Jason Gunthorpe
2019-07-22  9:44 ` [PATCH 6/6] mm: remove the legacy hmm_pfn_* APIs Christoph Hellwig
2019-07-23  1:11 ` hmm_range_fault related fixes and legacy API removal v2 Ralph Campbell
2019-07-23  1:11   ` Ralph Campbell
2019-07-23 15:20   ` Jason Gunthorpe
2019-07-23 15:20     ` Jason Gunthorpe
2019-07-23 15:27 ` Jason Gunthorpe
2019-07-23 16:32   ` Christoph Hellwig
  -- strict thread matches above, loose matches on Subject: below --
2019-07-03 22:02 Christoph Hellwig
2019-07-03 22:02 ` [PATCH 4/6] nouveau: unlock mmap_sem on all errors from nouveau_range_fault Christoph Hellwig

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=20190723151824.GL15331@mellanox.com \
    --to=jgg@mellanox.com \
    --cc=bskeggs@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hch@lst.de \
    --cc=jglisse@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=rcampbell@nvidia.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.