linux/drivers/gpu/drm/ttm, branch v3.8.1

drm/ttm: fix fence locking in ttm_buffer_object_transfer, 2nd try

2013-02-08T00:44:31Z

This fixes up commit e8e89622ed361c46bf90ba4828e685a8b603f7e5 Author: Daniel Vetter Date: Tue Dec 18 22:25:11 2012 +0100 drm/ttm: fix fence locking in ttm_buffer_object_transfer which leaves behind a might_sleep in atomic context, since the fence_lock spinlock is held over a kmalloc(GFP_KERNEL) call. The fix is to revert the above commit and only take the lock where we need it, around the call to ->sync_obj_ref. v2: Fixup things noticed by Maarten Lankhorst: - Brown paper bag locking bug. - No need for kzalloc if we clear the entire thing on the next line. - check for bo->sync_obj (totally unlikely race, but still someone else could have snuck in) and clear fbo->sync_obj if it's cleared already. Reported-by: Dave Airlie Cc: Jerome Glisse Cc: Maarten Lankhorst Signed-off-by: Daniel Vetter Signed-off-by: Dave Airlie

ttm: on move memory failure don't leave a node dangling

2013-01-21T03:45:23Z

if we have a move notify callback, when moving fails, we call move notify the opposite way around, however this ends up with *mem containing the mm_node from the bo, which means we double free it. This is a follow on to the previous fix. Reviewed-by: Jerome Glisse Signed-off-by: Dave Airlie

ttm: don't destroy old mm_node on memcpy failure

2013-01-21T03:45:02Z

When we are using memcpy to move objects around, and we fail to memcpy due to lack of memory to populate or failure to finish the copy, we don't want to destroy the mm_node that has been copied into old_copy. While working on a new kms driver that uses memcpy, if I overallocated bo's up to the memory limits, and eviction failed, then machine would oops soon after due to having an active bo with an already freed drm_mm embedded in it, freeing it a second time didn't end well. Reviewed-by: Jerome Glisse Signed-off-by: Dave Airlie

drm/ttm: fix fence locking in ttm_buffer_object_transfer

2013-01-08T08:35:31Z

Noticed while reviewing the fence locking in the radeon pageflip handler. v2: Instead of grabbing the bdev->fence_lock in object_transfer just move the single callsite of that function a few lines, so that it is protected by the fence_lock. Suggested by Jerome Glisse. v3: Fix typo in commit message. Reviewed-by: Jerome Glisse Signed-off-by: Daniel Vetter Signed-off-by: Dave Airlie

drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling

2012-12-19T21:46:20Z

Fix regression introduced by 85b144f860176 "drm/ttm: call ttm_bo_cleanup_refs with reservation and lru lock held, v3" Slowpath ttm_bo_cleanup_refs_and_unlock accidentally tried to increase refcount on &bo->sync_obj instead of bo->sync_obj. The compiler didn't complain since sync_obj_ref takes a void pointer, so it was still valid c. This could result in lockups, memory corruptions, and warnings like these when graphics card VRAM usage is high: ------------[ cut here ]------------ WARNING: at include/linux/kref.h:42 radeon_fence_ref+0x2c/0x40() Hardware name: System Product Name Pid: 157, comm: X Not tainted 3.7.0-rc7-00520-g85b144f-dirty #174 Call Trace: [] ? warn_slowpath_common+0x74/0xb0 [] ? radeon_fence_ref+0x2c/0x40 [] ? ttm_bo_cleanup_refs_and_unlock+0x18c/0x2d0 [] ? ttm_mem_evict_first+0x1dc/0x2a0 [] ? ttm_bo_man_get_node+0x62/0xb0 [] ? ttm_bo_mem_space+0x28e/0x340 [] ? ttm_bo_move_buffer+0xfc/0x170 [] ? kmem_cache_alloc+0xb2/0xc0 [] ? ttm_bo_validate+0x95/0x110 [] ? ttm_bo_init+0x2ec/0x3b0 [] ? radeon_bo_create+0x18a/0x200 [] ? radeon_bo_clear_va+0x40/0x40 [] ? radeon_gem_object_create+0x92/0x160 [] ? radeon_gem_create_ioctl+0x6c/0x150 [] ? radeon_gem_object_free+0x2f/0x40 [] ? drm_ioctl+0x420/0x4f0 [] ? radeon_gem_pwrite_ioctl+0x20/0x20 [] ? do_vfs_ioctl+0x2e4/0x4e0 [] ? vfs_read+0x118/0x160 [] ? sys_ioctl+0x4c/0xa0 [] ? sys_read+0x51/0xa0 [] ? system_call_fastpath+0x16/0x1b Signed-off-by: Maarten Lankhorst Reported-by: Markus Trippelsdorf Acked-by: Paul Menzel Signed-off-by: Dave Airlie

drm/ttm: remove no_wait_reserve, v3

2012-12-10T10:21:30Z

All items on the lru list are always reservable, so this is a stupid thing to keep. Not only that, it is used in a way which would guarantee deadlocks if it were ever to be set to block on reserve. This is a lot of churn, but mostly because of the removal of the argument which can be nested arbitrarily deeply in many places. No change of code in this patch except removal of the no_wait_reserve argument, the previous patch removed the use of no_wait_reserve. v2: - Warn if -EBUSY is returned on reservation, all objects on the list should be reservable. Adjusted patch slightly due to conflicts. v3: - Focus on no_wait_reserve removal only. Signed-off-by: Maarten Lankhorst Reviewed-by: Thomas Hellstrom Signed-off-by: Dave Airlie

drm/ttm: cope with reserved buffers on lru list in ttm_mem_evict_first, v2

2012-12-10T10:21:22Z

Replace the goto loop with a simple for each loop, and only run the delayed destroy cleanup if we can reserve the buffer first. No race occurs, since lru lock is never dropped any more. An empty list and a list full of unreservable buffers both cause -EBUSY to be returned, which is identical to the previous situation, because previously buffers on the lru list were always guaranteed to be reservable. This should work since currently ttm guarantees items on the lru are always reservable, and reserving items blockingly with some bo held are enough to cause you to run into a deadlock. Currently this is not a concern since removal off the lru list and reservations are always done with atomically, but when this guarantee no longer holds, we have to handle this situation or end up with possible deadlocks. Signed-off-by: Maarten Lankhorst Reviewed-by: Thomas Hellstrom Signed-off-by: Dave Airlie

drm/ttm: cope with reserved buffers on swap list in ttm_bo_swapout, v2

2012-12-10T10:21:06Z

Replace the while loop with a simple for each loop, and only run the delayed destroy cleanup if we can reserve the buffer first. No race occurs, since lru lock is never dropped any more. An empty list and a list full of unreservable buffers both cause -EBUSY to be returned, which is identical to the previous situation. Signed-off-by: Maarten Lankhorst Reviewed-by: Thomas Hellstrom Signed-off-by: Dave Airlie

drm/ttm: call ttm_bo_cleanup_refs with reservation and lru lock held, v3

2012-12-10T10:21:03Z

By removing the unlocking of lru and retaking it immediately, a race is removed where the bo is taken off the swap list or the lru list between the unlock and relock. As such the cleanup_refs code can be simplified, it will attempt to call ttm_bo_wait non-blockingly, and if it fails it will drop the locks and perform a blocking wait, or return an error if no_wait_gpu was set. The need for looping is also eliminated, since swapout and evict_mem_first will always follow the destruction path, no new fence is allowed to be attached. As far as I can see this may already have been the case, but the unlocking / relocking required a complicated loop to deal with re-reservation. Changes since v1: - Simplify no_wait_gpu case by folding it in with empty ddestroy. - Hold a reservation while calling ttm_bo_cleanup_memtype_use again. Changes since v2: - Do not remove bo from lru list while waiting Signed-off-by: Maarten Lankhorst Reviewed-by: Thomas Hellstrom Signed-off-by: Dave Airlie

drm/ttm: change fence_lock to inner lock

2012-12-10T10:09:58Z

This requires changing the order in ttm_bo_cleanup_refs_or_queue to take the reservation first, as there is otherwise no race free way to take lru lock before fence_lock. Signed-off-by: Maarten Lankhorst Reviewed-by: Thomas Hellstrom Signed-off-by: Dave Airlie