linux-stable.git/drivers/gpu/drm/xe/xe_exec_queue.c, branch linux-6.10.y

drm/xe: prevent UAF around preempt fence

2024-09-04T11:30:02+00:00

[ Upstream commit 730b72480e29f63fd644f5fa57c9d46109428953 ]

The fence lock is part of the queue, therefore in the current design
anything locking the fence should then also hold a ref to the queue to
prevent the queue from being freed.

However, currently it looks like we signal the fence and then drop the
queue ref, but if something is waiting on the fence, the waiter is
kicked to wake up at some later point, where upon waking up it first
grabs the lock before checking the fence state. But if we have already
dropped the queue ref, then the lock might already be freed as part of
the queue, leading to uaf.

To prevent this, move the fence lock into the fence itself so we don't
run into lifetime issues. Alternative might be to have device level
lock, or only release the queue in the fence release callback, however
that might require pushing to another worker to avoid locking issues.

Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2454
References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2342
References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2020
Signed-off-by: Matthew Auld 
Cc: Matthew Brost 
Cc:  # v6.8+
Reviewed-by: Matthew Brost 
Link: https://patchwork.freedesktop.org/patch/msgid/20240814110129.825847-2-matthew.auld@intel.com
(cherry picked from commit 7116c35aacedc38be6d15bd21b2fc936eed0008b)
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Sasha Levin

drm/xe/exec_queue: Rename xe_exec_queue::compute to xe_exec_queue::lr

2024-09-04T11:30:01+00:00

[ Upstream commit 731e46c032281601756f08cfa7d8505fe41166a9 ]

The properties of this struct are used in long running context so
make that clear by renaming it to lr, in alignment with the rest
of the code.

Cc: Matthew Brost 
Signed-off-by: Francois Dugast 
Reviewed-by: Matthew Brost 
Link: https://patchwork.freedesktop.org/patch/msgid/20240613170348.723245-1-francois.dugast@intel.com
Signed-off-by: Rodrigo Vivi 
Stable-dep-of: 730b72480e29 ("drm/xe: prevent UAF around preempt fence")
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: 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: Kill xe_device_mem_access_{get*,put}

2024-04-22T13:03:09+00:00

Let's simply convert all the current callers towards direct
xe_pm_runtime access and remove this extra layer of indirection.

No functional change is expected with this patch since
xe_mem_access_get was already using the xe_pm_runtime_get_noresume
at this point.

v2: Convert all the current callers instead of a big refactor
at once.

v3: - Rebased
    - Squashed the GSC/HDCP
    - Added a new case: sriov_pf_policy
    - Improved commit message to highlight that
      there's no functional change in this patch.

Reviewed-by: Matthew Auld  #v2
Cc: Suraj Kandpal 
Cc: Michal Wajdeczko 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Suraj Kandpal 
Link: https://patchwork.freedesktop.org/patch/msgid/20240418143049.43231-1-rodrigo.vivi@intel.com

drm/xe: Introduce xe_pm_runtime_get_noresume for inner callers

2024-04-18T12:31:39+00:00

Let's ensure that we have an option for inner callers that will
raise WARN if device is not active and not protected by outer callers.

Make this also a void function forcing every caller to unconditionally
put the reference back afterwards.

This will be very important for cases where we want to hold the
reference before scheduling a work in a queue. Then the work job
will be responsible for putting it back.

While at this, already convert a case from mem_access_get_ongoing where
it is not checking for the reference and put it back, what would
cause the underflow.

v2: Fix identation.
v3: Convert equivalent missing put from mem_access towards pm_runtime.

Reviewed-by: Matthew Auld 
Link: https://patchwork.freedesktop.org/patch/msgid/20240417203952.25503-1-rodrigo.vivi@intel.com
Signed-off-by: Rodrigo Vivi

drm/xe: prefer snprintf over sprintf

2024-04-04T18:54:51+00:00

since the sprintf() function lacks built-in protection against buffer
overflows using the snprintf() function.

v2: Removed hard coded values and used sizeof()

Signed-off-by: Bommu Krishnaiah 
Cc: Himal Prasad Ghimiray 
Cc: Tejas Upadhyay 
Reviewed-by: Himal Prasad Ghimiray 
Link: https://patchwork.freedesktop.org/patch/msgid/20231209235949.54524-2-krishnaiah.bommu@intel.com
Signed-off-by: Rodrigo Vivi

drm/xe: Use correct function pointer type

2024-03-20T05:36:38+00:00

Use xe_exec_queue_user_extension_fn type for
exec_queue_user_extension_funcs.`

Signed-off-by: Niranjana Vishwanathapura 
Reviewed-by: Ashutosh Dixit 
Signed-off-by: Matthew Brost 
Link: https://patchwork.freedesktop.org/patch/msgid/20240319174919.1847-1-niranjana.vishwanathapura@intel.com

drm/xe: Streamline exec queue freeing path

2024-03-20T05:36:30+00:00

Ensure exec queue freeing happens at one place, that is in
__xe_exec_queue_free(). It releases q->vm reference also. Set
q->vm before handling extensions as they can potentially reference it.

Signed-off-by: Niranjana Vishwanathapura 
Reviewed-by: Matthew Brost 
Signed-off-by: Matthew Brost 
Link: https://patchwork.freedesktop.org/patch/msgid/20240319175947.15890-1-niranjana.vishwanathapura@intel.com