Re: [PATCH v2 09/27] drm/sched: Add fair scheduling policy

["Danilo Krummrich" <dakr@kernel.org>]

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.