kernel/linux.git/drivers/gpu/drm/xe, branch v6.10.7

drm/xe: Do not dereference NULL job->fence in trace points

2024-08-29T15:36:12+00:00

commit 5d30de4311d2d4165e78dc021c5cacb7496b3491 upstream. job->fence is not assigned until xe_sched_job_arm(), check for job->fence in xe_sched_job_seqno() so any usage of this function (trace points) do not result in NULL ptr dereference. Also check job->fence before assigning error in job trace points. Fixes: 0ac7a2c745e8 ("drm/xe: Don't initialize fences at xe_sched_job_create()") Cc: Thomas Hellström Signed-off-by: Matthew Brost Reviewed-by: Lucas De Marchi Link: https://patchwork.freedesktop.org/patch/msgid/20240605055041.2082074-1-matthew.brost@intel.com Signed-off-by: Greg Kroah-Hartman

drm/xe: Free job before xe_exec_queue_put

2024-08-29T15:36:05+00:00

[ Upstream commit 9e7f30563677fbeff62d368d5d2a5ac7aaa9746a ] Free job depends on job->vm being valid, the last xe_exec_queue_put can destroy the VM. Prevent UAF by freeing job before xe_exec_queue_put. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Brost Reviewed-by: Nirmoy Das Reviewed-by: Jagmeet Randhawa Link: https://patchwork.freedesktop.org/patch/msgid/20240820202309.1260755-1-matthew.brost@intel.com (cherry picked from commit 32a42c93b74c8ca6d0915ea3eba21bceff53042f) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin

drm/xe: Don't initialize fences at xe_sched_job_create()

2024-08-29T15:36:05+00:00

[ Upstream commit 0ac7a2c745e8a42803378b944fa0f4455b7240f6 ] Pre-allocate but don't initialize fences at xe_sched_job_create(), and initialize / arm them instead at xe_sched_job_arm(). This makes it possible to move xe_sched_job_create() with its memory allocation out of any lock that is required for fence initialization, and that may not allow memory allocation under it. Replaces the struct dma_fence_array for parallell jobs with a struct dma_fence_chain, since the former doesn't allow a split-up between allocation and initialization. v2: - Rebase. - Don't always use the first lrc when initializing parallel lrc fences. - Use dma_fence_chain_contained() to access the lrc fences. v4: - Add an assert that job->lrc_seqno == fence->seqno. (Matthew Brost) Signed-off-by: Thomas Hellström Reviewed-by: Matthew Brost Reviewed-by: Rodrigo Vivi #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20240527135912.152156-4-thomas.hellstrom@linux.intel.com Stable-dep-of: 9e7f30563677 ("drm/xe: Free job before xe_exec_queue_put") Signed-off-by: Sasha Levin

drm/xe: Split lrc seqno fence creation up

2024-08-29T15:36:05+00:00

[ Upstream commit e183910ae4015214475b3248ce0b4c70f104f254 ] Since sometimes a lock is required to initialize a seqno fence, and it might be desirable not to hold that lock while performing memory allocations, split the lrc seqno fence creation up into an allocation phase and an initialization phase. Since lrc seqno fences under the hood are hw_fences, do the same for these and remove the xe_hw_fence_create() function since it is not used anymore. Signed-off-by: Thomas Hellström Reviewed-by: Matthew Brost Reviewed-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/20240527135912.152156-3-thomas.hellstrom@linux.intel.com Stable-dep-of: 9e7f30563677 ("drm/xe: Free job before xe_exec_queue_put") Signed-off-by: Sasha Levin

drm/xe: Decouple job seqno and lrc seqno

2024-08-29T15:36:05+00:00

[ Upstream commit 08f7200899ca72dec550af092ae424b7db099abd ] Tightly coupling these seqno presents problems if alternative fences for jobs are used. Decouple these for correctness. v2: - Slightly reword commit message (Thomas) - Make sure the lrc fence ops are used in comparison (Thomas) - Assume seqno is unsigned rather than signed in format string (Thomas) Cc: Thomas Hellström Signed-off-by: Matthew Brost Signed-off-by: Thomas Hellström Reviewed-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/20240527135912.152156-2-thomas.hellstrom@linux.intel.com Stable-dep-of: 9e7f30563677 ("drm/xe: Free job before xe_exec_queue_put") Signed-off-by: Sasha Levin

drm/xe: Relax runtime pm protection during execution

2024-08-29T15:36:04+00:00

[ Upstream commit ad1e331fc451a2cffc72ae193b843682ce237e24 ] Limit the protection only during moments of actual job execution, and introduce protection for guc submit fini, which is currently unprotected due to the absence of exec_queue life protection. In the regular use case scenario, user space will create an exec queue, and keep it alive to reuse that until it is done with that kind of workload. For the regular desktop cases, it means that the exec_queue is alive even on idle scenarios where display goes off. This is unacceptable since this would entirely block runtime PM indefinitely, blocking deeper Package-C state. This would be a waste drainage of power. Cc: Matthew Brost Tested-by: Francois Dugast Reviewed-by: Thomas Hellström Link: https://patchwork.freedesktop.org/patch/msgid/20240522170105.327472-3-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi Stable-dep-of: 9e7f30563677 ("drm/xe: Free job before xe_exec_queue_put") Signed-off-by: Sasha Levin

drm/xe: Fix missing workqueue destroy in xe_gt_pagefault

2024-08-29T15:36:04+00:00

[ Upstream commit a6f78359ac75f24cac3c1bdd753c49c1877bcd82 ] On driver reload we never free up the memory for the pagefault and access counter workqueues. Add those destroy calls here. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Stuart Summers Reviewed-by: Rodrigo Vivi Signed-off-by: Matthew Brost Link: https://patchwork.freedesktop.org/patch/msgid/c9a951505271dc3a7aee76de7656679f69c11518.1723862633.git.stuart.summers@intel.com (cherry picked from commit 7586fc52b14e0b8edd0d1f8a434e0de2078b7b2b) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin

drm/xe: Fix tile fini sequence

2024-08-29T15:36:04+00:00

[ Upstream commit 15939ca77d4424f736e1e4953b4da2351cc9689d ] Only set tile->mmio.regs to NULL if not the root tile in tile_fini. The root tile mmio regs is setup ealier in MMIO init thus it should be set to NULL in mmio_fini. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Brost Reviewed-by: Lucas De Marchi Reviewed-by: Himal Prasad Ghimiray Link: https://patchwork.freedesktop.org/patch/msgid/20240809232830.3302251-1-matthew.brost@intel.com (cherry picked from commit 3396900aa273903639a1792afa4d23dc09bec291) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin

drm/xe: reset mmio mappings with devm

2024-08-29T15:36:04+00:00

[ Upstream commit c7117419784f612d59ee565145f722e8b5541fe6 ] Set our various mmio mappings to NULL. This should make it easier to catch something rogue trying to mess with mmio after device removal. For example, we might unmap everything and then start hitting some mmio address which has already been unmamped by us and then remapped by something else, causing all kinds of carnage. Signed-off-by: Matthew Auld Cc: Andrzej Hajda Cc: Rodrigo Vivi Reviewed-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20240522102143.128069-33-matthew.auld@intel.com Stable-dep-of: 15939ca77d44 ("drm/xe: Fix tile fini sequence") Signed-off-by: Sasha Levin

drm/xe/mmio: move mmio_fini over to devm

2024-08-29T15:36:04+00:00

[ Upstream commit a0b834c8957a7d2848face008a12382a0ad11ffc ] Not valid to touch mmio once the device is removed, so make sure we unmap on removal and not just when driver instance goes away. Also set the mmio pointers to NULL to hopefully catch such issues more easily. Signed-off-by: Matthew Auld Cc: Andrzej Hajda Cc: Rodrigo Vivi Reviewed-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20240522102143.128069-32-matthew.auld@intel.com Stable-dep-of: 15939ca77d44 ("drm/xe: Fix tile fini sequence") Signed-off-by: Sasha Levin