On Wed Oct 22, 2025 at 3:50 PM CEST, Tvrtko Ursulin wrote:
> Yes, for the case when entity joins the run-queue it can be the same
> entity which is now the head of the queue, or it can be a different one.
> Depends on the insertion position.
>
> But for the case where entity is leaving the run queue it is always a
> different entity and therefore a lock inversion. We have essentially this:
>
> lock entity
> lock rq
> remove entity from the rq
> rq->prio = rq->head_entity->prio // different entity, unlocked read
> unlock rq
> unlock entity
This sounds like it repeates the unclear locking situation that is also
documented for struct drm_sched_rq:
* FIXME: Locking is very unclear for this. Writers are protected by
* @lock, but readers are generally lockless and seem to just race with
* not even a READ_ONCE.
This sounds pretty suspicious to me and I think it indicates a more fundamental
design issue that you now end up working around now.
I'd like to dig in a bit more, but unfortunately it's very unlikely I will have
the time to do this until after LPC.
