From: Francisco Jerez <[email protected]> ===================================================================== | This is a commit scheduled for the next v2.6.34 longterm release. | | If you see a problem with using this for longterm, please comment.| =====================================================================
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 <[email protected]> Reviewed-by: Jerome Glisse <[email protected]> Tested-by: Marcin Slusarz <[email protected]> Signed-off-by: Francisco Jerez <[email protected]> Signed-off-by: Dave Airlie <[email protected]> Signed-off-by: Paul Gortmaker <[email protected]> --- drivers/gpu/drm/ttm/ttm_bo_util.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c index d764e82..fe04f8c 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_util.c +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c @@ -327,6 +327,7 @@ static int ttm_buffer_object_transfer(struct ttm_buffer_object *bo, 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) -- 1.7.4.4 _______________________________________________ stable mailing list [email protected] http://linux.kernel.org/mailman/listinfo/stable
