Re: [PATCH v2 2/5] drm/xe/vf: Avoid LRC being freed while applying fixups

[Matthew Brost <matthew.brost@intel.com>]

On Thu, Feb 19, 2026 at 12:21:55AM +0100, Tomasz Lis wrote:
> There is a small but non-zero chance that fixups are running on
> a context during teardown. The chances are decreased by starting
> the teardown by releasing guc_id, but remain non-zero.
> On the other hand the sync between fixups and context creation
> drastically increases chance for such parallel teardown if
> context creation fails.
> 

I don't see how this is possible.

xe_exec_queue_contexts_hwsp_rebase only happens if the exec queue is
present in &guc->submission_state.exec_queue_lookup.

 332 static void __xe_exec_queue_fini(struct xe_exec_queue *q)
 333 {
 334         int i;
 335
 336         q->ops->fini(q);
 337
 338         for (i = 0; i < q->width; ++i)
 339                 xe_lrc_put(q->lrc[i]);
 340 }

The removal from &guc->submission_state.exec_queue_lookup happen on line
336 in the above before. Thus a xe_exec_queue_contexts_hwsp_rebase can't
be executing on a 'q' after line 336 returns, then we drop the
references to the LRC. I agree this lifetime is questionable at best
(IIRC my GuC documentation explain this why this works) but if there is
a problem it should be fix with this lifetime in mind.

Looking at __xe_exec_queue_init, I believe 'err_lrc' label should
actually call __xe_exec_queue_fini.

> Prevent LRC teardown in parallel with fixups by getting a reference.
> 
> Signed-off-by: Tomasz Lis <tomasz.lis@intel.com>
> ---
>  drivers/gpu/drm/xe/xe_exec_queue.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_exec_queue.c b/drivers/gpu/drm/xe/xe_exec_queue.c
> index 42849be46166..e9396ad3390a 100644
> --- a/drivers/gpu/drm/xe/xe_exec_queue.c
> +++ b/drivers/gpu/drm/xe/xe_exec_queue.c
> @@ -1669,10 +1669,11 @@ int xe_exec_queue_contexts_hwsp_rebase(struct xe_exec_queue *q, void *scratch)
>  		lrc = READ_ONCE(q->lrc[i]);
>  		if (!lrc)
>  			continue;
> -
> +		xe_lrc_get(lrc);

This doesn't actually fix anything. The LRC could (current, in error
paths) disappear between the read and get.

Matt

>  		xe_lrc_update_memirq_regs_with_address(lrc, q->hwe, scratch);
>  		xe_lrc_update_hwctx_regs_with_address(lrc);
>  		err = xe_lrc_setup_wa_bb_with_scratch(lrc, q->hwe, scratch);
> +		xe_lrc_put(lrc);
>  		if (err)
>  			break;
>  	}
> -- 
> 2.25.1
>