diff options
| author | Thomas Hellstrom <thellstrom@vmware.com> | 2013-11-14 10:49:05 -0800 |
|---|---|---|
| committer | Thomas Hellstrom <thellstrom@vmware.com> | 2013-11-20 03:46:54 -0800 |
| commit | c58f009e01c918717379c206a63baa66f56a77f9 (patch) | |
| tree | ca283d5304390d33e526788141923f8db2008c51 /include | |
| parent | 0bc254257bfd9b25f64a68b719ee70a303b6d051 (diff) | |
| download | linux-exynos-c58f009e01c918717379c206a63baa66f56a77f9.tar.gz linux-exynos-c58f009e01c918717379c206a63baa66f56a77f9.tar.bz2 linux-exynos-c58f009e01c918717379c206a63baa66f56a77f9.zip | |
drm/ttm: Remove set_need_resched from the ttm fault handler
Addresses
"[BUG] completely bonkers use of set_need_resched + VM_FAULT_NOPAGE".
In the first occurence it was used to try to be nice while releasing the
mmap_sem and retrying the fault to work around a locking inversion.
The second occurence was never used.
There has been some discussion whether we should change the locking order to
mmap_sem -> bo_reserve. This patch doesn't address that issue, and leaves
that locking order undefined. The solution that we release the mmap_sem if
tryreserve fails and wait for the buffer to become unreserved is something
we want in any case, and follows how the core vm system waits for pages
to be come unlocked while releasing the mmap_sem.
The code also outlines what needs to be changed if we want to establish the
locking order as mmap_sem -> bo::reserve.
One slight issue that remains with this code is that the fault handler might
be prone to starvation if another thread countinously reserves the buffer.
IMO that usage pattern is highly unlikely.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Diffstat (limited to 'include')
| -rw-r--r-- | include/drm/ttm/ttm_bo_api.h | 4 |
1 files changed, 3 insertions, 1 deletions
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h index 751eaffbf0d5..ee127ec33c60 100644 --- a/include/drm/ttm/ttm_bo_api.h +++ b/include/drm/ttm/ttm_bo_api.h @@ -169,6 +169,7 @@ struct ttm_tt; * @offset: The current GPU offset, which can have different meanings * depending on the memory type. For SYSTEM type memory, it should be 0. * @cur_placement: Hint of current placement. + * @wu_mutex: Wait unreserved mutex. * * Base class for TTM buffer object, that deals with data placement and CPU * mappings. GPU mappings are really up to the driver, but for simpler GPUs @@ -250,6 +251,7 @@ struct ttm_buffer_object { struct reservation_object *resv; struct reservation_object ttm_resv; + struct mutex wu_mutex; }; /** @@ -702,5 +704,5 @@ extern ssize_t ttm_bo_io(struct ttm_bo_device *bdev, struct file *filp, size_t count, loff_t *f_pos, bool write); extern void ttm_bo_swapout_all(struct ttm_bo_device *bdev); - +extern int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo); #endif |