Re: [drm-intel/topic/core-for-CI] Revert "io_uring/sqpoll: don't attach to a thread that is canceling"

[Rodrigo Vivi <rodrigo.vivi@intel.com>]

On Mon, Nov 02, 2026 at 01:26:44PM -0800, Matt Roper wrote:
> On Mon, Nov 02, 2026 at 12:17:05PM -0800, Umesh Nerlige Ramappa wrote:
> > On Mon, Nov 02, 2026 at 12:06:04PM -0800, Umesh Nerlige Ramappa wrote:
> > > This reverts commit 22d9db9fd64a493525d692b32c556875b7254665.
> > > 
> > > This is resulting in igt@runner@aborted on Xe and i915 runs, so
> > > reverting the patch. The actual fix is still in flight on the kernel ML:
> > > 
> > > [PATCH] io_uring/sqpoll: don't set IO_SQ_THREAD_SHOULD_STOP on thread exit
> > > 
> > > Until that lands, revert this one.
> > > 
> > > Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
> > > References: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/17747
> > 
> > Not sure I got the references right here. I ended up adding the i915 failure
> > instance of the gitlab issue.
> > 
> > Instead should I create a gitlab item to track actual fix and then drop this
> > commit?
> 
> Yeah, the issue you linked here is going to here will be "fixed" by the
> revert you're providing and closed.  We need a separate ticket to track
> the future work of removing this commit from the for-CI branch once a
> proper fix exists in the baseline kernel.
> 
> BTW, if the actual fix on lkml that you mention is looking like it's in
> good shape, applying a copy of that patch in topic/core-for-CI rather
> than reverting the bad patch is another alternative.

In this case, where we have a simple revert, I agree with Umesh that this
might be the less impactful option to our CI.

We can update later if we see the patch progressed.

Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

> 
> 
> Matt
> 
> > 
> > Thanks,
> > Umesh
> > 
> > > ---
> > > io_uring/sqpoll.c | 11 +----------
> > > 1 file changed, 1 insertion(+), 10 deletions(-)
> > > 
> > > diff --git a/io_uring/sqpoll.c b/io_uring/sqpoll.c
> > > index c833e776320d..49c52284ecdd 100644
> > > --- a/io_uring/sqpoll.c
> > > +++ b/io_uring/sqpoll.c
> > > @@ -433,12 +433,6 @@ static int io_sq_thread(void *data)
> > > 	if (io_sq_tw_pending())
> > > 		io_sq_tw(UINT_MAX);
> > > 
> > > -	/*
> > > -	 * Cancelation drops sqd->lock while it waits, and a ring could attach
> > > -	 * to a thread that is on its way out. A fatal signal doesn't set the
> > > -	 * bit, so set it here for io_sq_offload_create() to see.
> > > -	 */
> > > -	set_bit(IO_SQ_THREAD_SHOULD_STOP, &sqd->state);
> > > 	io_uring_cancel_generic(true, sqd);
> > > 	rcu_assign_pointer(sqd->thread, NULL);
> > > 	put_task_struct(current);
> > > @@ -508,10 +502,7 @@ __cold int io_sq_offload_create(struct io_ring_ctx *ctx,
> > > 		list_add(&ctx->sqd_list, &sqd->ctx_list);
> > > 		io_sqd_update_thread_idle(sqd);
> > > 		/* don't attach to a dying SQPOLL thread, would be racy */
> > > -		ret = 0;
> > > -		if (attached && (!sqd->thread ||
> > > -		    test_bit(IO_SQ_THREAD_SHOULD_STOP, &sqd->state)))
> > > -			ret = -ENXIO;
> > > +		ret = (attached && !sqd->thread) ? -ENXIO : 0;
> > > 		io_sq_thread_unpark(sqd);
> > > 
> > > 		if (ret < 0)
> > > -- 
> > > 2.55.0
> > > 
> 
> -- 
> Matt Roper
> Graphics Software Engineer
> Linux GPU Platform Enablement
> Intel Corporation