[PATCH] instmem/gk20a: exclusively acquire instobjs

[PATCH] instmem/gk20a: exclusively acquire instobjs

[Alexandre Courbot]

Although I would not have expected this to happen, we seem to run into
race conditions if instobjs are accessed concurrently. Use a global lock
for safety.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
 drm/nouveau/nvkm/subdev/instmem/gk20a.c | 15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drm/nouveau/nvkm/subdev/instmem/gk20a.c b/drm/nouveau/nvkm/subdev/instmem/gk20a.c
index fc419bb8eab7..d015633b8edd 100644
--- a/drm/nouveau/nvkm/subdev/instmem/gk20a.c
+++ b/drm/nouveau/nvkm/subdev/instmem/gk20a.c
@@ -92,6 +92,7 @@ struct gk20a_instmem {
 
 	/* protects vaddr_* and gk20a_instobj::vaddr* */
 	spinlock_t lock;
+	unsigned long flags;
 
 	/* CPU mappings LRU */
 	unsigned int vaddr_use;
@@ -188,12 +189,11 @@ gk20a_instobj_acquire(struct nvkm_memory *memory)
 	struct gk20a_instobj *node = gk20a_instobj(memory);
 	struct gk20a_instmem *imem = node->imem;
 	struct nvkm_ltc *ltc = imem->base.subdev.device->ltc;
-	const u64 size = nvkm_memory_size(memory);
-	unsigned long flags;
+	u64 size;
 
 	nvkm_ltc_flush(ltc);
 
-	spin_lock_irqsave(&imem->lock, flags);
+	spin_lock_irqsave(&imem->lock, imem->flags);
 
 	if (node->vaddr) {
 		/* remove us from the LRU list since we cannot be unmapped */
@@ -202,6 +202,8 @@ gk20a_instobj_acquire(struct nvkm_memory *memory)
 		goto out;
 	}
 
+	size = nvkm_memory_size(memory);
+
 	/* try to free some address space if we reached the limit */
 	gk20a_instmem_vaddr_gc(imem, size);
 
@@ -218,8 +220,6 @@ gk20a_instobj_acquire(struct nvkm_memory *memory)
 		   imem->vaddr_use, imem->vaddr_max);
 
 out:
-	spin_unlock_irqrestore(&imem->lock, flags);
-
 	return node->vaddr;
 }
 
@@ -229,14 +229,11 @@ gk20a_instobj_release(struct nvkm_memory *memory)
 	struct gk20a_instobj *node = gk20a_instobj(memory);
 	struct gk20a_instmem *imem = node->imem;
 	struct nvkm_ltc *ltc = imem->base.subdev.device->ltc;
-	unsigned long flags;
-
-	spin_lock_irqsave(&imem->lock, flags);
 
 	/* add ourselves to the LRU list so our CPU mapping can be freed */
 	list_add_tail(&node->vaddr_node, &imem->vaddr_lru);
 
-	spin_unlock_irqrestore(&imem->lock, flags);
+	spin_unlock_irqrestore(&imem->lock, imem->flags);
 
 	wmb();
 	nvkm_ltc_invalidate(ltc);
-- 
2.6.1

_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [PATCH] instmem/gk20a: exclusively acquire instobjs

[Ben Skeggs]

[-- Attachment #1.1: Type: text/plain, Size: 2772 bytes --]

On 10/26/2015 03:54 PM, Alexandre Courbot wrote:
> Although I would not have expected this to happen, we seem to run into
> race conditions if instobjs are accessed concurrently. Use a global lock
> for safety.
I wouldn't expect this to be an issue either.

Before merging such a large hammer of a fix, I'd strongly prefer to see
at least a better justification for why this is happening rather than
potentially papering over a larger issue.

Ben.

> 
> Signed-off-by: Alexandre Courbot <acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
>  drm/nouveau/nvkm/subdev/instmem/gk20a.c | 15 ++++++---------
>  1 file changed, 6 insertions(+), 9 deletions(-)
> 
> diff --git a/drm/nouveau/nvkm/subdev/instmem/gk20a.c b/drm/nouveau/nvkm/subdev/instmem/gk20a.c
> index fc419bb8eab7..d015633b8edd 100644
> --- a/drm/nouveau/nvkm/subdev/instmem/gk20a.c
> +++ b/drm/nouveau/nvkm/subdev/instmem/gk20a.c
> @@ -92,6 +92,7 @@ struct gk20a_instmem {
>  
>  	/* protects vaddr_* and gk20a_instobj::vaddr* */
>  	spinlock_t lock;
> +	unsigned long flags;
>  
>  	/* CPU mappings LRU */
>  	unsigned int vaddr_use;
> @@ -188,12 +189,11 @@ gk20a_instobj_acquire(struct nvkm_memory *memory)
>  	struct gk20a_instobj *node = gk20a_instobj(memory);
>  	struct gk20a_instmem *imem = node->imem;
>  	struct nvkm_ltc *ltc = imem->base.subdev.device->ltc;
> -	const u64 size = nvkm_memory_size(memory);
> -	unsigned long flags;
> +	u64 size;
>  
>  	nvkm_ltc_flush(ltc);
>  
> -	spin_lock_irqsave(&imem->lock, flags);
> +	spin_lock_irqsave(&imem->lock, imem->flags);
>  
>  	if (node->vaddr) {
>  		/* remove us from the LRU list since we cannot be unmapped */
> @@ -202,6 +202,8 @@ gk20a_instobj_acquire(struct nvkm_memory *memory)
>  		goto out;
>  	}
>  
> +	size = nvkm_memory_size(memory);
> +
>  	/* try to free some address space if we reached the limit */
>  	gk20a_instmem_vaddr_gc(imem, size);
>  
> @@ -218,8 +220,6 @@ gk20a_instobj_acquire(struct nvkm_memory *memory)
>  		   imem->vaddr_use, imem->vaddr_max);
>  
>  out:
> -	spin_unlock_irqrestore(&imem->lock, flags);
> -
>  	return node->vaddr;
>  }
>  
> @@ -229,14 +229,11 @@ gk20a_instobj_release(struct nvkm_memory *memory)
>  	struct gk20a_instobj *node = gk20a_instobj(memory);
>  	struct gk20a_instmem *imem = node->imem;
>  	struct nvkm_ltc *ltc = imem->base.subdev.device->ltc;
> -	unsigned long flags;
> -
> -	spin_lock_irqsave(&imem->lock, flags);
>  
>  	/* add ourselves to the LRU list so our CPU mapping can be freed */
>  	list_add_tail(&node->vaddr_node, &imem->vaddr_lru);
>  
> -	spin_unlock_irqrestore(&imem->lock, flags);
> +	spin_unlock_irqrestore(&imem->lock, imem->flags);
>  
>  	wmb();
>  	nvkm_ltc_invalidate(ltc);
> 


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [PATCH] instmem/gk20a: exclusively acquire instobjs

[Alexandre Courbot]

On Thu, Nov 5, 2015 at 6:19 AM, Ben Skeggs <skeggsb@gmail.com> wrote:
> On 10/26/2015 03:54 PM, Alexandre Courbot wrote:
>> Although I would not have expected this to happen, we seem to run into
>> race conditions if instobjs are accessed concurrently. Use a global lock
>> for safety.
> I wouldn't expect this to be an issue either.
>
> Before merging such a large hammer of a fix, I'd strongly prefer to see
> at least a better justification for why this is happening rather than
> potentially papering over a larger issue.

I was afraid you would say that. ;)

But you're right. I am really busy with lots of stuff but will try to
rootcause this more precisely...
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [PATCH] instmem/gk20a: exclusively acquire instobjs

[Alexandre Courbot]

On Thu, Nov 5, 2015 at 3:44 PM, Alexandre Courbot <gnurou@gmail.com> wrote:
> On Thu, Nov 5, 2015 at 6:19 AM, Ben Skeggs <skeggsb@gmail.com> wrote:
>> On 10/26/2015 03:54 PM, Alexandre Courbot wrote:
>>> Although I would not have expected this to happen, we seem to run into
>>> race conditions if instobjs are accessed concurrently. Use a global lock
>>> for safety.
>> I wouldn't expect this to be an issue either.
>>
>> Before merging such a large hammer of a fix, I'd strongly prefer to see
>> at least a better justification for why this is happening rather than
>> potentially papering over a larger issue.
>
> I was afraid you would say that. ;)
>
> But you're right. I am really busy with lots of stuff but will try to
> rootcause this more precisely...

Turns out this was just me not knowing how to handle concurrency properly. >_<

Fortunately this means that the error was just confined to the gk20a
implementation and is not part of something larger. I will send the
correct fixup patch later today.

Thanks for refusing my lazy hacks! :)
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau