linux-stable.git/drivers/gpu/drm/ttm, branch linux-5.4.y

Revert "drm/ttm: fix memleak in ttm_transfered_destroy"

2021-11-06T12:59:45+00:00

This reverts commit bd99782f3ca491879e8524c89b1c0f40071903bd which is
commit 0db55f9a1bafbe3dac750ea669de9134922389b5 upstream.

Seems that the older kernels can not handle this fix because, to quote
Christian:
	The problem is this memory leak could potentially happen with
	5.10 as wel, just much much much less likely.

	But my guess is that 5.10 is so buggy that when the leak does
	NOT happen we double free and obviously causing a crash.

So it needs to be reverted.

Link: https://lore.kernel.org/r/1a1cc125-9314-f569-a6c4-40fc4509a377@amd.com
Cc: Christian König 
Cc: Erhard F. 
Cc: Erhard F. 
Cc: Huang Rui 
Signed-off-by: Greg Kroah-Hartman

drm/ttm: fix memleak in ttm_transfered_destroy

2021-11-02T18:46:13+00:00

commit 0db55f9a1bafbe3dac750ea669de9134922389b5 upstream.

We need to cleanup the fences for ghost objects as well.

Signed-off-by: Christian König 
Reported-by: Erhard F. 
Tested-by: Erhard F. 
Reviewed-by: Huang Rui 
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=214029
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=214447
CC: 
Link: https://patchwork.freedesktop.org/patch/msgid/20211020173211.2247-1-christian.koenig@amd.com
Signed-off-by: Greg Kroah-Hartman

drm/ttm: fix eviction valuable range check.

2020-11-05T10:43:35+00:00

commit fea456d82c19d201c21313864105876deabe148b upstream.

This was adding size to start, but pfn and start are in pages,
so it should be using num_pages.

Not sure this fixes anything in the real world, just noticed it
during refactoring.

Signed-off-by: Dave Airlie 
Reviewed-by: Christian König 
Cc: stable@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20201019222257.1684769-2-airlied@gmail.com
Signed-off-by: Greg Kroah-Hartman

drm/ttm: fix offset in VMAs with a pg_offs in ttm_bo_vm_access

2020-08-26T08:40:56+00:00

[ Upstream commit c0001213d195d1bac83e0744c06ff06dd5a8ba53 ]

VMAs with a pg_offs that's offset from the start of the vma_node need
to adjust the offset within the BO accordingly. This matches the
offset calculation in ttm_bo_vm_fault_reserved.

Signed-off-by: Felix Kuehling 
Tested-by: Laurent Morichetti 
Signed-off-by: Christian König 
Link: https://patchwork.freedesktop.org/patch/381169/
Signed-off-by: Sasha Levin

drm/ttm/nouveau: don't call tt destroy callback on alloc failure.

2020-08-19T06:16:24+00:00

commit 5de5b6ecf97a021f29403aa272cb4e03318ef586 upstream.

This is confusing, and from my reading of all the drivers only
nouveau got this right.

Just make the API act under driver control of it's own allocation
failing, and don't call destroy, if the page table fails to
create there is nothing to cleanup here.

(I'm willing to believe I've missed something here, so please
review deeply).

Reviewed-by: Christian König 
Signed-off-by: Dave Airlie 
Link: https://patchwork.freedesktop.org/patch/msgid/20200728041736.20689-1-airlied@gmail.com
Signed-off-by: Greg Kroah-Hartman

drm/ttm: Fix dma_fence refcnt leak when adding move fence

2020-07-16T06:16:33+00:00

[ Upstream commit 11425c4519e2c974a100fc984867046d905b9380 ]

ttm_bo_add_move_fence() invokes dma_fence_get(), which returns a
reference of the specified dma_fence object to "fence" with increased
refcnt.

When ttm_bo_add_move_fence() returns, local variable "fence" becomes
invalid, so the refcount should be decreased to keep refcount balanced.

The reference counting issue happens in one exception handling path of
ttm_bo_add_move_fence(). When no_wait_gpu flag is equals to true, the
function forgets to decrease the refcnt increased by dma_fence_get(),
causing a refcnt leak.

Fix this issue by calling dma_fence_put() when no_wait_gpu flag is
equals to true.

Signed-off-by: Xiyu Yang 
Signed-off-by: Xin Tan 
Reviewed-by: Christian König 
Link: https://patchwork.freedesktop.org/patch/370221/
Signed-off-by: Christian König 
Signed-off-by: Sasha Levin

drm/ttm: flush the fence on the bo after we individualize the reservation object

2020-04-23T08:36:27+00:00

[ Upstream commit 1bbcf69e42fe7fd49b6f4339c970729d0e343753 ]

As we move the ttm_bo_individualize_resv() upwards, we need flush the
copied fence too. Otherwise the driver keeps waiting for fence.

run&Kill kfdtest, then perf top.

  25.53%  [ttm]                     [k] ttm_bo_delayed_delete
  24.29%  [kernel]                  [k] dma_resv_test_signaled_rcu
  19.72%  [kernel]                  [k] ww_mutex_lock

Fix: 378e2d5b("drm/ttm: fix ttm_bo_cleanup_refs_or_queue once more")
Signed-off-by: xinhui pan 
Reviewed-by: Christian König 
Link: https://patchwork.freedesktop.org/series/72339/
Signed-off-by: Christian König 
Signed-off-by: Sasha Levin

drm/ttm: return -EBUSY on pipelining with no_gpu_wait (v2)

2019-12-31T15:43:00+00:00

[ Upstream commit 3084cf46cf8110826a42de8c8ef30e8fa48974c2 ]

Setting the no_gpu_wait flag means that the allocate BO must be available
immediately and we can't wait for any GPU operation to finish.

v2: squash in mem leak fix, rebase

Signed-off-by: Christian König 
Acked-by: Felix Kuehling 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/ttm: fix handling in ttm_bo_add_mem_to_lru

2019-10-14T11:21:15+00:00

We should not add the BO to the swap LRU when the new mem is fixed and
the TTM object about to be destroyed.

Signed-off-by: Christian König 
Reviewed-by: Kevin Wang 
Link: https://patchwork.freedesktop.org/patch/335246/

drm/ttm: Restore ttm prefaulting

2019-10-14T10:49:24+00:00

Commit 4daa4fba3a38 ("gpu: drm: ttm: Adding new return type vm_fault_t")
broke TTM prefaulting. Since vmf_insert_mixed() typically always returns
VM_FAULT_NOPAGE, prefaulting stops after the second PTE.

Restore (almost) the original behaviour. Unfortunately we can no longer
with the new vm_fault_t return type determine whether a prefaulting
PTE insertion hit an already populated PTE, and terminate the insertion
loop. Instead we continue with the pre-determined number of prefaults.

Fixes: 4daa4fba3a38 ("gpu: drm: ttm: Adding new return type vm_fault_t")
Cc: Souptick Joarder 
Cc: Christian König 
Signed-off-by: Thomas Hellstrom 
Reviewed-by: Christian König 
Cc: stable@vger.kernel.org # v4.19+
Signed-off-by: Christian König 
Link: https://patchwork.freedesktop.org/patch/330387/