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

[Andrea Righi <arighi@nvidia.com>]

On Sun, Apr 20, 2025 at 07:44:12AM -1000, Tejun Heo wrote:
> 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?

Oh ok, I was only thinking of setting the percpu variable when we call
SCX_CALL_OP*(), but if we clear it after the scx op returns, then it should
work. If no rq is locked and we bounce to a different CPU, we'd still read
NULL, so it should be always correct.

Alright, I'll send a v2 with this logic and the percpu variable.

Thanks,
-Andrea