Re: [PATCH] sched_ext: Fix spurious WARN on stale ops_state in ops_dequeue()

[Andrea Righi]

Hi Samuele,

On Thu, May 14, 2026 at 11:13:49AM +0200, Samuele Mariotti wrote:
> Hi Tejun,
> 
> > Let's not do the WARN and exit. We shouldn't get this wrong and if we get
> > this wrong, it's going to be obvious from lockup detectors. Can you please
> > add a comment explaining the retry condition tho?
> > 
> > Thanks.
> > 
> > -- 
> > tejun
> 
> Thanks for the feedback. If I understood correctly, you prefer no retry
> limit, letting the lockup detectors catch any real bug. I also added
> unlikely() since the stale case is by definition rare.
> 
> Here is the updated version:
> 
> /*
>  * If SCX_TASK_IN_CUSTODY is not set, opss is stale: finish_dispatch()
>  * has already claimed the task and cleared SCX_TASK_IN_CUSTODY. Retry
>  * to get a fresh view of p->scx.ops_state.
>  */
> if (unlikely(!(READ_ONCE(p->scx.flags) & SCX_TASK_IN_CUSTODY))) {
>     cpu_relax();
>     goto retry;
> }

The code looks good to me, I'd elaborate more on the comment to make it clear
that the retry loop is guaranteed to terminate (not a deadlock).

How about this (or something along these lines)?

 /*
  * A queued task must be in BPF scheduler's custody. If
  * SCX_TASK_IN_CUSTODY is clear, finish_dispatch() on another
  * CPU has already passed call_task_dequeue() (which clears the
  * flag), but has not yet written SCX_OPSS_NONE. That final
  * store does not require this rq's lock, so retrying with
  * cpu_relax() is bounded: we'll observe NONE (or DISPATCHING,
  * handled by the fallthrough) on a subsequent iteration.
  */

Thanks,
-Andrea