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

[K Prateek Nayak]

Hello Gabriele,

On 6/29/2026 6:10 PM, Gabriele Monaco wrote:
> On Mon, 2026-06-29 at 09:41 +0530, K Prateek Nayak wrote:
>> Unrelated to changes here: This tracepoint seems to be missing from
>> wake_up_idle_cpu() which modifies the ti->flags without taking the
>> rq_lock.
>>
>> A newly enqueued timer can race with the wakeup on idle CPU and you can
>> see a wakeup + sched_switch without seeing a corresponding
>> trace_sched_set_need_resched_tp() for the CPU.
>>
>> Gabriele, is that a concern for RV?
> 
> Thanks Prateek for pointing this out. So as I'm understanding, we are missing
> the tracepoint in that path, but even after putting it, this race might cause a
> sched_switch to be visible concurrently or before the corresponding need_resched
> for that CPU, right?

Ack but if that comment in wake_up_idle_cpu() is accurate, it is a very
infrequent operation and we might be able to get away with grabbing the
rq_lock and synchronizing it too.

> 
> That's potentially an issue.
> 
> Currently the only model really relying on the need_resched event is nrp,
> validating every kernel preemption has a corresponding need_resched set.
> The scenario passing through wake_up_idle_cpu() is setting the flag on a CPU
> that is idle (causing __schedule(SM_IDLE)), this doesn't count as a preemption
> for the model. Or am I missing something?

I just saw the npr monitor and yes, the SM_IDLE path will not count as
preemption and the state machine should just stay at
"any_thread_running" from the "schedule_entry" edge.

Sorry for the scare!

> That said, we should indeed add the tracepoint to that path and probably adapt
> the monitor if that's making it fail indirectly.

For the npr use-case, I think the current scheme is fine since
only SM_PREEMPt counts as a "schedule_entry_preempt" transition
and only that can transition the state machine out of the
"any_thread_running" state.

-- 
Thanks and Regards,
Prateek