kernel/linux.git/drivers/gpu/drm/ttm, branch v3.16.50

drm/ttm, drm/vmwgfx: Relax permission checking when opening surfaces

2017-07-18T17:40:26+00:00

commit fe25deb7737ce6c0879ccf79c99fa1221d428bf2 upstream. Previously, when a surface was opened using a legacy (non prime) handle, it was verified to have been created by a client in the same master realm. Relax this so that opening is also allowed recursively if the client already has the surface open. This works around a regression in svga mesa where opening of a shared surface is used recursively to obtain surface information. Signed-off-by: Thomas Hellstrom Reviewed-by: Sinclair Yeh [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings

drm/ttm: fix use-after-free races in vm fault handling

2017-06-05T20:17:12+00:00

commit 3089c1df10e2931b1d72d2ffa7d86431084c86b3 upstream. The vm fault handler relies on the fact that the VMA owns a reference to the BO. However, once mmap_sem is released, other tasks are free to destroy the VMA, which can lead to the BO being freed. Fix two code paths where that can happen, both related to vm fault retries. Found via a lock debugging warning which flagged &bo->wu_mutex as locked while being destroyed. Fixes: cbe12e74ee4e ("drm/ttm: Allow vm fault retries") Signed-off-by: Nicolai Hähnle Reviewed-by: Christian König Signed-off-by: Alex Deucher [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings

drm/ttm: Make sure BOs being swapped out are cacheable

2017-06-05T20:16:59+00:00

commit 239ac65fa5ffab71adf66e642750f940e7241d99 upstream. The current caching state may not be tt_cached, even though the placement contains TTM_PL_FLAG_CACHED, because placement can contain multiple caching flags. Trying to swap out such a BO would trip up the BUG_ON(ttm->caching_state != tt_cached); in ttm_tt_swapout. Signed-off-by: Michel Dänzer Reviewed-by: Thomas Hellstrom Reviewed-by: Christian König . Reviewed-by: Sinclair Yeh Signed-off-by: Christian König Signed-off-by: Ben Hutchings

drm/ttm: Fixed a read/write lock imbalance

2016-01-11T10:50:16+00:00

commit 025af189fb44250206dd8a32fa4a682392af3301 upstream. In ttm_write_lock(), the uninterruptible path should call __ttm_write_lock() not __ttm_read_lock(). This fixes a vmwgfx hang on F23 start up. syeh: Extracted this from one of Thomas' internal patches. Signed-off-by: Thomas Hellstrom Reviewed-by: Sinclair Yeh Signed-off-by: Luis Henriques

drm/ttm: Avoid memory allocation from shrinker functions.

2015-01-05T13:48:48+00:00

commit 881fdaa5e4cb0d68e52acab0ad4e1820e2bfffa4 upstream. Andrew Morton wrote: > On Wed, 12 Nov 2014 13:08:55 +0900 Tetsuo Handa wrote: > > > Andrew Morton wrote: > > > Poor ttm guys - this is a bit of a trap we set for them. > > > > Commit a91576d7916f6cce ("drm/ttm: Pass GFP flags in order to avoid deadlock.") > > changed to use sc->gfp_mask rather than GFP_KERNEL. > > > > - pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), > > - GFP_KERNEL); > > + pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp); > > > > But this bug is caused by sc->gfp_mask containing some flags which are not > > in GFP_KERNEL, right? Then, I think > > > > - pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp); > > + pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp & GFP_KERNEL); > > > > would hide this bug. > > > > But I think we should use GFP_ATOMIC (or drop __GFP_WAIT flag) > > Well no - ttm_page_pool_free() should stop calling kmalloc altogether. > Just do > > struct page *pages_to_free[16]; > > and rework the code to free 16 pages at a time. Easy. Well, ttm code wants to process 512 pages at a time for performance. Memory footprint increased by 512 * sizeof(struct page *) buffer is only 4096 bytes. What about using static buffer like below? ---------- >From d3cb5393c9c8099d6b37e769f78c31af1541fe8c Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Thu, 13 Nov 2014 22:21:54 +0900 Subject: [PATCH] drm/ttm: Avoid memory allocation from shrinker functions. Commit a91576d7916f6cce ("drm/ttm: Pass GFP flags in order to avoid deadlock.") caused BUG_ON() due to sc->gfp_mask containing flags which are not in GFP_KERNEL. https://bugzilla.kernel.org/show_bug.cgi?id=87891 Changing from sc->gfp_mask to (sc->gfp_mask & GFP_KERNEL) would avoid the BUG_ON(), but avoiding memory allocation from shrinker function is better and reliable fix. Shrinker function is already serialized by global lock, and clean up function is called after shrinker function is unregistered. Thus, we can use static buffer when called from shrinker function and clean up function. Signed-off-by: Tetsuo Handa Signed-off-by: Dave Airlie Signed-off-by: Luis Henriques

drm/ttm: Don't evict BOs outside of the requested placement range

2014-11-14T15:20:05+00:00

commit e300180f71037fd9ed1ca967006fd9f3ee466bcd upstream. The radeon driver uses placement range restrictions for several reasons, in particular to make sure BOs in VRAM can be accessed by the CPU, e.g. during a page fault. Without this change, TTM could evict other BOs while trying to satisfy the requested placement, even if the evicted BOs were outside of the requested placement range. Doing so didn't free up any space in the requested placement range, so the (potentially high) eviction cost was incurred for no benefit. Nominating for stable because radeon driver changes in 3.17 made this much more noticeable than before. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84662 Signed-off-by: Michel Dänzer Signed-off-by: Alex Deucher [ luis: backported to 3.16: based on Michel's backport ] Signed-off-by: Luis Henriques

drm/ttm: Pass GFP flags in order to avoid deadlock.

2014-10-05T20:40:51+00:00

commit a91576d7916f6cce76d30303e60e1ac47cf4a76d upstream. Commit 7dc19d5a "drivers: convert shrinkers to new count/scan API" added deadlock warnings that ttm_page_pool_free() and ttm_dma_page_pool_free() are currently doing GFP_KERNEL allocation. But these functions did not get updated to receive gfp_t argument. This patch explicitly passes sc->gfp_mask or GFP_KERNEL to these functions, and removes the deadlock warning. Signed-off-by: Tetsuo Handa Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

drm/ttm: Fix possible stack overflow by recursive shrinker calls.

2014-10-05T20:40:51+00:00

commit 71336e011d1d2312bcbcaa8fcec7365024f3a95d upstream. While ttm_dma_pool_shrink_scan() tries to take mutex before doing GFP_KERNEL allocation, ttm_pool_shrink_scan() does not do it. This can result in stack overflow if kmalloc() in ttm_page_pool_free() triggered recursion due to memory pressure. shrink_slab() => ttm_pool_shrink_scan() => ttm_page_pool_free() => kmalloc(GFP_KERNEL) => shrink_slab() => ttm_pool_shrink_scan() => ttm_page_pool_free() => kmalloc(GFP_KERNEL) Change ttm_pool_shrink_scan() to do like ttm_dma_pool_shrink_scan() does. Signed-off-by: Tetsuo Handa Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

drm/ttm: Use mutex_trylock() to avoid deadlock inside shrinker functions.

2014-10-05T20:40:51+00:00

commit 22e71691fd54c637800d10816bbeba9cf132d218 upstream. I can observe that RHEL7 environment stalls with 100% CPU usage when a certain type of memory pressure is given. While the shrinker functions are called by shrink_slab() before the OOM killer is triggered, the stall lasts for many minutes. One of reasons of this stall is that ttm_dma_pool_shrink_count()/ttm_dma_pool_shrink_scan() are called and are blocked at mutex_lock(&_manager->lock). GFP_KERNEL allocation with _manager->lock held causes someone (including kswapd) to deadlock when these functions are called due to memory pressure. This patch changes "mutex_lock();" to "if (!mutex_trylock()) return ...;" in order to avoid deadlock. Signed-off-by: Tetsuo Handa Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

drm/ttm: Choose a pool to shrink correctly in ttm_dma_pool_shrink_scan().

2014-10-05T20:40:50+00:00

commit 46c2df68f03a236b30808bba361f10900c88d95e upstream. We can use "unsigned int" instead of "atomic_t" by updating start_pool variable under _manager->lock. This patch will make it possible to avoid skipping when choosing a pool to shrink in round-robin style, after next patch changes mutex_lock(_manager->lock) to !mutex_trylock(_manager->lork). Signed-off-by: Tetsuo Handa Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman