Inside ____active_del_barrier(), while searching for a node to be deleted,
we now rebuild barrier_tasks llist content in reverse order.
Theoretically neutral, that method was observed to provide an undocumented
workaround for unexpected loops of llist nodes appearing now and again due
to races, silently breaking those llist node loops, then protecting
llist_for_each_safe() from spinning indefinitely.
Having all races hopefully fixed, make that function behavior more
predictable, more easy to follow -- switch to an alternative, equally
simple but less invasive algorithm that only updates a link between list
nodes that precede and follow the deleted node.
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@xxxxxxxxxxxxxxx>
---
drivers/gpu/drm/i915/i915_active.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c b/drivers/gpu/drm/i915/i915_active.c
index 8eb10af7928f4..10f52eb4a4592 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -391,13 +391,14 @@ static bool ____active_del_barrier(struct i915_active *ref,
llist_for_each_safe(pos, next, llist_del_all(&engine->barrier_tasks)) {
if (node == barrier_from_ll(pos)) {
node = NULL;
+ if (tail)
+ tail->next = next;
continue;
}
- pos->next = head;
- head = pos;
- if (!tail)
- tail = pos;
+ if (!head)
+ head = pos;
+ tail = pos;
}
if (head)
llist_add_batch(head, tail, &engine->barrier_tasks);
--
2.25.1
