[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20101208004430.103698335@clark.site>
Date: Tue, 07 Dec 2010 16:44:04 -0800
From: Greg KH <gregkh@...e.de>
To: linux-kernel@...r.kernel.org, stable@...nel.org
Cc: stable-review@...nel.org, torvalds@...ux-foundation.org,
akpm@...ux-foundation.org, alan@...rguk.ukuu.org.uk,
Francisco Jerez <currojerez@...eup.net>,
Dave Airlie <airlied@...hat.com>
Subject: [058/127] drm/ttm: Clear the ghost cpu_writers flag on ttm_buffer_object_transfer.
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Francisco Jerez <currojerez@...eup.net>
commit 0fbecd400dd0a82d465b3086f209681e8c54cb0f upstream.
It makes sense for a BO to move after a process has requested
exclusive RW access on it (e.g. because the BO used to be located in
unmappable VRAM and we intercepted the CPU access from the fault
handler).
If we let the ghost object inherit cpu_writers from the original
object, ttm_bo_release_list() will raise a kernel BUG when the ghost
object is destroyed. This can be reproduced with the nouveau driver on
nv5x.
Reported-by: Marcin Slusarz <marcin.slusarz@...il.com>
Reviewed-by: Jerome Glisse <jglisse@...hat.com>
Tested-by: Marcin Slusarz <marcin.slusarz@...il.com>
Signed-off-by: Francisco Jerez <currojerez@...eup.net>
Signed-off-by: Dave Airlie <airlied@...hat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@...e.de>
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -330,6 +330,7 @@ static int ttm_buffer_object_transfer(st
INIT_LIST_HEAD(&fbo->lru);
INIT_LIST_HEAD(&fbo->swap);
fbo->vm_node = NULL;
+ atomic_set(&fbo->cpu_writers, 0);
fbo->sync_obj = driver->sync_obj_ref(bo->sync_obj);
if (fbo->mem.mm_node)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists