kernel/linux.git/drivers/gpu/drm/ttm, branch v5.14.8

drm/ttm: Fix a deadlock if the target BO is not idle during swap

2021-09-26T12:10:20+00:00

[ Upstream commit 70982eef4d7eebb47a3b1ef25ec1bc742f3a21cf ] The ret value might be -EBUSY, caller will think lru lock is still locked but actually NOT. So return -ENOSPC instead. Otherwise we hit list corruption. ttm_bo_cleanup_refs might fail too if BO is not idle. If we return 0, caller(ttm_tt_populate -> ttm_global_swapout ->ttm_device_swapout) will be stuck as we actually did not free any BO memory. This usually happens when the fence is not signaled for a long time. Signed-off-by: xinhui pan Reviewed-by: Christian König Fixes: ebd59851c796 ("drm/ttm: move swapout logic around v3") Link: https://patchwork.freedesktop.org/patch/msgid/20210907040832.1107747-1-xinhui.pan@amd.com Signed-off-by: Christian König Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin

drm/ttm: Fix ttm_bo_move_memcpy() for subclassed struct ttm_resource

2021-09-18T11:44:04+00:00

commit efcefc7127290e7e9fa98dea029163ad8eda8fb3 upstream. The code was making a copy of a struct ttm_resource. However, recently the struct ttm_resources were allowed to be subclassed and also were allowed to be malloced, hence the driver could end up assuming the copy we handed it was subclassed and worse, the original could have been freed at this point. Fix this by using the original struct ttm_resource before it is potentially freed in ttm_bo_move_sync_cleanup() v2: Base on drm-misc-next-fixes rather than drm-tip. Reported-by: Ben Skeggs Reported-by: Dave Airlie Cc: Christian König Cc: Fixes: 3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move for page-based iomem") Signed-off-by: Thomas Hellström Reviewed-by: Christian König Reviewed-by: Ben Skeggs Link: https://patchwork.freedesktop.org/patch/msgid/20210831071536.80636-1-thomas.hellstrom@linux.intel.com Signed-off-by: Greg Kroah-Hartman

drm/ttm: Fix multihop assert on eviction.

2021-09-18T11:43:35+00:00

[ Upstream commit 403797925768d9fa870f5b1ebcd20016b397083b ] Problem: Under memory pressure when GTT domain is almost full multihop assert will come up when trying to evict LRU BO from VRAM to SYSTEM. Fix: Don't assert on multihop error in evict code but rather do a retry as we do in ttm_bo_move_buffer Signed-off-by: Andrey Grodzovsky Reviewed-by: Christian König Link: https://patchwork.freedesktop.org/patch/msgid/20210622162339.761651-6-andrey.grodzovsky@amd.com Signed-off-by: Sasha Levin

drm: ttm: Don't bail from ttm_global_init if debugfs_create_dir fails

2021-08-16T12:11:51+00:00

In 69de4421bb4c ("drm/ttm: Initialize debugfs from ttm_global_init()"), ttm_global_init was changed so that if creation of the debugfs global root directory fails, ttm_global_init will bail out early and return an error, leading to initialization failure of DRM drivers. However, not every system will be using debugfs. On such a system, debugfs directory creation can be expected to fail, but DRM drivers must still be usable. This changes it so that if creation of TTM's debugfs root directory fails, then no biggie: keep calm and carry on. Fixes: 69de4421bb4c ("drm/ttm: Initialize debugfs from ttm_global_init()") Signed-off-by: Dan Moulding Tested-by: Huacai Chen Reviewed-by: Huang Rui Reviewed-by: Christian König Link: https://patchwork.freedesktop.org/patch/msgid/20210810195906.22220-2-dmoulding@me.com Signed-off-by: Christian König

drm/ttm: Initialize debugfs from ttm_global_init()

2021-07-22T10:09:12+00:00

We create a bunch of debugfs entries as a side-effect of ttm_global_init() and then never clean them up. This isn't usually a problem because we free the whole debugfs directory on module unload. However, if the global reference count ever goes to zero and then ttm_global_init() is called again, we'll re-create those debugfs entries and debugfs will complain in dmesg that we're creating entries that already exist. This patch fixes this problem by changing the lifetime of the whole TTM debugfs directory to match that of the TTM global state. Signed-off-by: Jason Ekstrand Reviewed-by: Daniel Vetter Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210721152358.2893314-6-jason@jlekstrand.net

drm/ttm: add missing NULL checks

2021-07-21T11:00:40+00:00

My local syzbot instance hit GPF in ttm_bo_release(). Unfortunately, syzbot didn't produce a reproducer for this, but I found out possible scenario: drm_gem_vram_create() <-- drm_gem_vram_object kzalloced (bo embedded in this object) ttm_bo_init() ttm_bo_init_reserved() ttm_resource_alloc() man->func->alloc() <-- allocation failure ttm_bo_put() ttm_bo_release() ttm_mem_io_free() <-- bo->resource == NULL passed as second argument *GPF* Added NULL check inside ttm_mem_io_free() to prevent reported GPF and make this function NULL save in future. Same problem was in ttm_bo_move_to_lru_tail() as Christian reported. ttm_bo_move_to_lru_tail() is called in ttm_bo_release() and mem pointer can be NULL as well as in ttm_mem_io_free(). Fail log: KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] ... RIP: 0010:ttm_mem_io_free+0x28/0x170 drivers/gpu/drm/ttm/ttm_bo_util.c:66 .. Call Trace: ttm_bo_release+0xd94/0x10a0 drivers/gpu/drm/ttm/ttm_bo.c:422 kref_put include/linux/kref.h:65 [inline] ttm_bo_put drivers/gpu/drm/ttm/ttm_bo.c:470 [inline] ttm_bo_init_reserved+0x7cb/0x960 drivers/gpu/drm/ttm/ttm_bo.c:1050 ttm_bo_init+0x105/0x270 drivers/gpu/drm/ttm/ttm_bo.c:1074 drm_gem_vram_create+0x332/0x4c0 drivers/gpu/drm/drm_gem_vram_helper.c:228 Fixes: d3116756a710 ("drm/ttm: rename bo->mem and make it a pointer") Signed-off-by: Pavel Skripkin Reviewed-by: Christian König Signed-off-by: Christian König Link: https://patchwork.freedesktop.org/patch/msgid/20210708112518.17271-1-paskripkin@gmail.com

drm/ttm: Force re-init if ttm_global_init() fails

2021-07-21T06:34:43+00:00

If we have a failure, decrement the reference count so that the next call to ttm_global_init() will actually do something instead of assume everything is all set up. Signed-off-by: Jason Ekstrand Fixes: 62b53b37e4b1 ("drm/ttm: use a static ttm_bo_global instance") Reviewed-by: Christian König Link: https://patchwork.freedesktop.org/patch/msgid/20210720181357.2760720-5-jason@jlekstrand.net Signed-off-by: Christian König

drm/ttm: add a check against null pointer dereference

2021-07-14T15:16:16+00:00

When calling ttm_range_man_fini(), 'man' may be uninitialized, which may cause a null pointer dereference bug. Fix this by checking if it is a null pointer. This log reveals it: [ 7.902580 ] BUG: kernel NULL pointer dereference, address: 0000000000000058 [ 7.905721 ] RIP: 0010:ttm_range_man_fini+0x40/0x160 [ 7.911826 ] Call Trace: [ 7.911826 ] radeon_ttm_fini+0x167/0x210 [ 7.911826 ] radeon_bo_fini+0x15/0x40 [ 7.913767 ] rs400_fini+0x55/0x80 [ 7.914358 ] radeon_device_fini+0x3c/0x140 [ 7.914358 ] radeon_driver_unload_kms+0x5c/0xe0 [ 7.914358 ] radeon_driver_load_kms+0x13a/0x200 [ 7.914358 ] ? radeon_driver_unload_kms+0xe0/0xe0 [ 7.914358 ] drm_dev_register+0x1db/0x290 [ 7.914358 ] radeon_pci_probe+0x16a/0x230 [ 7.914358 ] local_pci_probe+0x4a/0xb0 Signed-off-by: Zheyu Ma Reviewed-by: Christian König Link: https://patchwork.freedesktop.org/patch/msgid/1626274459-8148-1-git-send-email-zheyuma97@gmail.com Signed-off-by: Christian König

Backmerge tag 'v5.13-rc7' into drm-next

2021-06-23T00:07:48+00:00

Backmerge Linux 5.13-rc7 to make some pulls from later bases apply, and to bake in the conflicts so far.

drm/ttm: fix deref of bo->ttm without holding the lock v2

2021-06-08T11:24:15+00:00

We need to grab the resv lock first before doing that check. v2 (chk): simplify the change for -fixes Signed-off-by: Christian König Signed-off-by: Thomas Hellström Reviewed-by: Huang Rui Link: https://patchwork.freedesktop.org/patch/msgid/20210528130041.1683-1-christian.koenig@amd.com