Re: [PATCH v3] sched: set TIF_NEED_RESCHED before calling __trace_set_need_resched()

[Andrea Righi]

Hi Gabriele,

On Tue, Sep 29, 2026 at 10:50:48AM +0200, Gabriele Monaco wrote:
> Hi Andrea,
> 
> On Mon, 2026-09-28 at 19:19 +0200, Andrea Righi wrote:
> > This leaves the race Prateek described in the v2 discussion: a remote CPU sets
> > TIF_NEED_RESCHED under rq->lock, but the target CPU can emit sched_entry_tp()
> > before acquiring that lock, ahead of the need-resched tracepoint.
> > 
> > I reproduced it with this applied to tip/master. With the RV nrp monitor
> > enabled, 300 runs of "perf bench sched messaging -g 20 -l 100" produced:
> > 
> >   rv: monitor nrp does not allow event schedule_entry_preempt on state
> > any_thread_running
> > 
> > Applying the following on top fixed the ordering, the same 300-run test then
> > completed without an RV violation. If it makes sense, could you fold this
> > change into v4?
> > 
> > Thanks,
> > -Andrea
> 
> thanks for looking into this. Is this change required for anything else besides
> fixing the nrp monitor after changing the order with need_resched?

No, I was mainly trying to help get this fix upstream: a sched_ext kselftest I'm
working on hits that issue and I'm holding off on submitting the test until the
fix lands. Moving sched_entry was only my attempt to address the nrp warning I
saw while testing the fix.

> 
> I believe this would break the sts monitor which expects sched_entry before
> disabling interrupts.
> 
> Both monitors could be adapted to either case, but if your change is just for
> the sake of nrp, I think it's easier to just allow this race, since nrp is
> already allowing the race with interrupts.
> I haven't tested yet, but something like allowing a sched_entry_preempt without
> need_resched set but provided it's going to be set before sched_exit would
> probably do (it'd allow also independent need_resched there, but those will then
> need their own preemption too).
> 
> I'd say if you don't need to move sched_entry for other reasons we can wait to
> apply this change until I see what's better for the models.

That makes sense, we can ignore the sched_entry change for now. With that,
Sechang's fix looks good to me.

Reviewed-by: Andrea Righi <arighi@xxxxxxxxxx>

Thanks,
-Andrea