| Message ID | 20230313172415.125932-4-janusz.krzysztofik@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | drm/i915/active: Fix other potential list corruption root causes | expand |
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);
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@linux.intel.com> --- drivers/gpu/drm/i915/i915_active.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)