Re: [PATCH 1/2] sched_ext: Track currently locked rq

Tejun Heo
2025-04-20T17:44:14Z

Hello,

On Sat, Apr 19, 2025 at 10:30:33PM +0200, Andrea Righi wrote:
> Hm... actually thinking more about this, a problem with the percpu variable
> is that, if no rq is locked, we could move to a different CPU and end up
> reading the wrong rq_locked via scx_locked_rq(). I don't think we want to
> preempt_disable/enable all the callbacks just to fix this... Maybe storing
> in current is a safer choice?

Hmm... I have a hard time imagining a timeline of events which would lead to
the wrong conclusion. The percpu variable is set only while an rq is locked
and cleared before the rq lock is released and thus can only be read as
non-NULL while the rq is locked by that CPU. Maybe I'm missing something.
Can you illustrate a timeline of events which would lead to the wrong
conclusion?

Thanks.

--
tejun