Skip to contentSkip to conversation

Patch "drm/i915: Always reset vma->ggtt_view.pages cache on unbinding" has been added to the 4.0-stable tree

PATCH [email protected] 1 participant 1 message Jun 23, 2015

Subsystems (3)
lore
Share & tools
lore

[email protected]

author maintainer Applied
#0 lore raw

This is a note to let you know that I've just added the patch titled

    drm/i915: Always reset vma->ggtt_view.pages cache on unbinding

to the 4.0-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
drm-i915-always-reset-vma-ggtt_view.pages-cache-on-unbinding.patch
and it can be found in the queue-4.0 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

Quoted 1 line

From 016a65a39170c3cdca09a6ac343ff4f124668b45 Mon Sep 17 00:00:00 2001

From: Chris Wilson <[email protected]>
Date: Thu, 11 Jun 2015 08:06:08 +0100
Subject: drm/i915: Always reset vma->ggtt_view.pages cache on unbinding

From: Chris Wilson <[email protected]>

commit 016a65a39170c3cdca09a6ac343ff4f124668b45 upstream.

With the introduction of multiple views of an obj in the same vm, each vma was taught to cache its copy of the pages (so that different views could have different page arrangements). However, this missed decoupling those vma->ggtt_view.pages when the vma released its reference on the obj->pages. As we don't always free the vma, this leads to a possible scenario (e.g. execbuffer interrupted by the shrinker) where the vma points to a stale obj->pages, and explodes.

Fixes regression from commit fe14d5f4e5468c5b80a24f1a64abcbe116143670

Author: Tvrtko Ursulin <[email protected]>
Date:   Wed Dec 10 17:27:58 2014 +0000

drm/i915: Infrastructure for supporting different GGTT views per object

Tvrtko says, if someone else will be confused how this can happen, key is the reservation execbuffer path. That puts the VMA on the exec_list which prevents i915_vma_unbind and i915_gem_vma_destroy from fully destroying the VMA. So the VMA is left existing as an empty object in the list - unbound and disassociated with the backing store. Kind of a cached memory object. And then re-using it needs to clear the cached pages pointer which is fixed above.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1227892

Cc Tvrtko Ursulin <[email protected]>
Cc Daniel Vetter <[email protected]>
Cc Michel Thierry <[email protected]>
[Jani: Added Tvrtko's explanation to commit message.]
---
 drivers/gpu/drm/i915/i915_gem.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/i915/i915_gem.c +1 -1
@@ -3088,8 +3088,8 @@ int i915_vma_unbind(struct i915_vma *vma
 		} else if (vma->ggtt_view.pages) {
 			sg_free_table(vma->ggtt_view.pages);
 			kfree(vma->ggtt_view.pages);
-			vma->ggtt_view.pages = NULL;
 		}
+		vma->ggtt_view.pages = NULL;
 	}
 
 	drm_mm_remove_node(&vma->node);

Patches currently in stable-queue which might be from [email protected] are

queue-4.0/drm-i915-always-reset-vma-ggtt_view.pages-cache-on-unbinding.patch --
To unsubscribe from this list: send the line "unsubscribe stable" in