<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [CI][DRMTIP] igt@perf_pmu@* - dmesg-warn / incomplete - WARNING: possible circular locking dependency detected" href="https://bugs.freedesktop.org/show_bug.cgi?id=109385#c2">Comment # 2</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [CI][DRMTIP] igt@perf_pmu@* - dmesg-warn / incomplete - WARNING: possible circular locking dependency detected" href="https://bugs.freedesktop.org/show_bug.cgi?id=109385">bug 109385</a> from <a class="email" href="mailto:chris@chris-wilson.co.uk" title="Chris Wilson <chris@chris-wilson.co.uk>"> Chris Wilson</a> <pre>This is close to being a WONTFIX as for us it is nigh on impossible to fix. perf allocates from inside per-cpu smpboot callback, tainting the cpuhp mutex used for stop-machine. We need to use stop-machine from any context to prevent the HW issue... Or we need to do something like revoke all mmaps before any GGTT update (which sounds even worse than stop-machine). Even breaking away from struct_mutex won't help here as the same chain will be created for ggtt->vm.mutex (both required from inside i915_gem_fault and then taking stop-machine for the ggtt insertion). So the most realistic coarse of action would be to avoid the same perf lock being required inside cpuhp and around the perf_event.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are on the CC list for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>