Re: [PATCH v30 7/7] sched: Add deactivated (sleeping) owner handling to find_proxy_task()

[John Stultz]

On Thu, Jul 9, 2026 at 9:04 PM K Prateek Nayak <kprateek.nayak@xxxxxxx> wrote:
> On 7/8/2026 10:04 AM, John Stultz wrote:
> > Let me take a stab at fixing that.  I'm thinking it might be easier to
> > check on_rq again after we take the blocked lock before calling
> > proxy_enqueue_on_owner(), because otherwise unwinding that is a little
> > complicated (pulling it off the list isn't, but the task will have
> > been blocked, which isn't what we want if we are going to pick again
> > to figure out if we can proxy or have to migrate the waiter).  Am I
> > still missing a race with that approach (instead of adding to the list
> > before the check)?
>
> I think it is safe since the unlock on owner->blocked_on will act as a
> release barrier ordering owner->on_rq = TASK_ON_RQ_QUEUED  when the
> owner wakes up and the grabbing the owner->blocked_lock in
> find_proxy_task() adds acquire semantic before the onwer->on_rq load.
>
> Only downside is you'll need to check list_empty() within the
> blocked_lock lock critical section.

I believe we currently do, but let me know if I'm missing something there.


> >> On a separate note, is it worth tracking if the task is a mutex / lock
> >> owner and only go through the activate_blocked_waiters() path only when
> >> a __mutex_owner() somewhere can return the task being activated? Perhaps
> >> a per-task counter that increments at every mutex_lock() and decrements
> >> at a mutex_unlock()?
> >
> > This as an optimization to avoid taking the owner->blocked_lock and
> > the list checking?
>
> Ack! I had some more interesting (read stupid) ideas on top with that
> but I'll try to see if it survives a boot before bombarding  you with
> them :-)

Ok, looking forward to it!

> > Let me think on that a bit.
> > For normal mutexes it seems easy enough but I want to make sure it
> > doesn't get complicated with ww_mutexes or the later proxy-rwsem
> > support from the full series.
>
> So, with rwsem, I recently realized there is {down,up}_read_non_owner()
> which is interesting, but I don't think we set a p->blocked_on for those
> cases and since the "owner" is always NULL, I doubt the limit usage of
> it in the kernel even cares for priority inheritance.
>
> Apart from that case, I don't think there is any other extra creative
> locking patterns possible that don't have symmetry for lock and unlock.

Thanks as always for your suggestions and guidance here! Very much appreciated!
-john