Test-with: <20230213095040.13457-2-janusz.krzysztofik@xxxxxxxxxxxxxxx> Users reported oopses on list corruptions when using i915 perf with a number of concurrently running graphics applications. Root cause analysis pointed out to an issue in barrier processing code -- a race among perf open / close replacing active barriers with perf requests on kernel contexts and concurrent barrier preallocate / acquire operations performed during user context first pin / last unpin. Respect results of barrier deletion attempts -- mark the barrier as idle only after successfully deleted from the list. Then, before proceeding with setting our fence as the one currently tracked, make sure that the tracker we've got is not a non-idle barrier. If that check fails, don't use that tracker but go back and try to acquire a new, usable one. Note: I'm submitting this fix with a request to CI for testing it with a new subtest igt@gem_barrier_race@remote-request, developed for that case, not yet in upstream IGT. I've selected trybot submission of the test, with the test added to BAT testlist, to get results from the widest possible HW range. Janusz Krzysztofik (1): drm/i915/active: Fix misuse of non-idle barriers as fence trackers drivers/gpu/drm/i915/i915_active.c | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-) -- 2.25.1
