Re: [BUG] Apparent lost wakeups

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Oct 13, 2026 at 12:16:11PM +0530, K Prateek Nayak wrote:
> On 10/13/2026 11:36 AM, K Prateek Nayak wrote:
> >> The following command reproduces the lost-wakeup problem, which shows
> >> up as RCU CPU stall warnings caused by rcu_torture_reader() kthreads:
> >>
> >> tools/testing/selftests/rcutorture/bin/kvm.sh --allcpus --duration 20m --configs '19*TREE01' --bootargs "nohz=off rcutorture.onoff_interval=0 rcutorture.nocbs_nthreads=0 rcutorture.shuffle_interval=0" --trust-make
> > 
> > tl;dr
> > 
> > I could hit that WARN_ON() from your debug patch with the above test
> > even under rq_lock. Seemed like a missing resched_curr() but it
> > turned out to also be related to rq->next_class interaction.
> > 
> > I haven't been able to hit the warnings with the below diff. Could
> > you please try this:
> > 
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index 0f63c30b4324..f2f8af3cdfb5 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -11239,6 +11245,11 @@ void sched_change_end(struct sched_change_ctx *ctx)
> >  		if (p->sched_class->switched_to)
> >  			p->sched_class->switched_to(rq, p);
> >  
> > +		if (ctx->queued && sched_class_above(p->sched_class, rq->next_class)) {
> > +			rq->next_class = p->sched_class;
> > +			resched_curr(rq);
> > +		}
> > +
> >  		if (ctx->running) {
> >  			/*
> >  			 * If this was a class promotion; let the old class
> > ---
> 
> And now that I've finally woken up just like that task, it can be
> simplified to:
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 0f63c30b4324..b37c771c41ad 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -11256,6 +11262,9 @@ void sched_change_end(struct sched_change_ctx *ctx)
>  			 */
>  			if (sched_class_above(ctx->class, p->sched_class))
>  				resched_curr(rq);
> +		} else if (ctx->queued) {
> +			/* Check if we need can preempt the current task. */
> +			wakeup_preempt(rq, p, 0);
>  		}
>  	} else {
>  		p->sched_class->prio_changed(rq, p, ctx->prio);
> ---
> 
> Peter, what do you think?

I am confused is what.

So a non-running, but queued task is changing class and then somehow its
not getting scheduled?

So I perhaps see why the whole if (ctx->running) thing might be too
strong; I mean if a queued task gets promoted from OTHER to FIFO, we
need a preemption, but that's not the case at hand, is it?

Somehow we're getting stuck in IDLE with runnable tasks on; and I'm just
not seeing how we get there.