On 08/10/2026 11:18, Philipp Stanner wrote:
On Fri, 2026-10-02 at 13:46 +0100, Tvrtko Ursulin wrote:
When the out of range priority at entity init time is clamped to the
number of run queues in the supplied scheduler the internal run-queue
priority needs to be adjusted as well.
There is no impact since none of the drivers hit the clamping path, but
we still need to address it by moving the entity->rq_priority assignment
to after the clamping is done.
Note that a lot of this will hopefully get removed once again when the
single run-queue simplification lands.
Signed-off-by: Tvrtko Ursulin <[email protected]>
Fixes: 2fa4d8e2c109 ("drm/sched: Add fair scheduling policy")
Help me out here; we recently landed this fix [1] that Luke reported.
Is there a relation? I guess not, since you say there is "no impact".
This did not exist before CFS in drm_sched, did it? Did you discover it
by review?
Bug did not exist neither before CFS, nor with full CFS. It surfaced
after the reverts of FIFO and RR removals and the single run-queue
simplification. So the bug was in the middle of the original CFS series.
And there is indeed no impact, it's only theoretical. There would only
be impact if any of the in-tree drivers would passing an entity to
drm_sched_entity_init, with a scheduler which has fewer priority levels
(run-queues) than the entity. And I am pretty sure no driver does that
otherwise this would be firing:
dev_err(sched_list[0]->dev, "entity with out-of-bounds priority:%u
num_user_rqs:%u\n",...)
Which was there for ages, added in
2bbe6ab2be53 ("drm/sched: Fix bounds limiting when given a malformed
entity")
which says it should not happen. So it would have been noticed.
And yes, I spotted this while working on patches leading to the spsc
removal.
Once we re-land the single run-queue simplification the check and error
log get removed once again. But until then I think it makes sense to
have the code fully theoretically correct.
Tvrtko
