Commit 31b57683 authored by Matthew Auld's avatar Matthew Auld Committed by Rodrigo Vivi

drm/xe/guc_submit: prevent repeated unregister

It seems that various things can trigger the lr cleanup worker,
including CAT error, engine reset and destroying the actual engine, so
seems plausible to end up triggering the worker more than once in some
cases. If that does happen we can race with an ongoing engine deregister
before it has completed, thus triggering it again and also changing the
state back into pending_disable. Checking if the engine has been marked
as destroyed looks like it should prevent this.
Signed-off-by: default avatarMatthew Auld <matthew.auld@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: default avatarMatthew Brost <matthew.brost@intel.com>
Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
parent d8b4494b
...@@ -802,8 +802,18 @@ static void xe_guc_exec_queue_lr_cleanup(struct work_struct *w) ...@@ -802,8 +802,18 @@ static void xe_guc_exec_queue_lr_cleanup(struct work_struct *w)
/* Kill the run_job / process_msg entry points */ /* Kill the run_job / process_msg entry points */
xe_sched_submission_stop(sched); xe_sched_submission_stop(sched);
/* Engine state now stable, disable scheduling / deregister if needed */ /*
if (exec_queue_registered(q)) { * Engine state now mostly stable, disable scheduling / deregister if
* needed. This cleanup routine might be called multiple times, where
* the actual async engine deregister drops the final engine ref.
* Calling disable_scheduling_deregister will mark the engine as
* destroyed and fire off the CT requests to disable scheduling /
* deregister, which we only want to do once. We also don't want to mark
* the engine as pending_disable again as this may race with the
* xe_guc_deregister_done_handler() which treats it as an unexpected
* state.
*/
if (exec_queue_registered(q) && !exec_queue_destroyed(q)) {
struct xe_guc *guc = exec_queue_to_guc(q); struct xe_guc *guc = exec_queue_to_guc(q);
int ret; int ret;
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment