| Summary: | [CI] igt@gem_userptr_blits@map-fixed-invalidate-gup - dmesg-warn: WARNING: possible circular locking dependency detected | ||
|---|---|---|---|
| Product: | DRI | Reporter: | Marta Löfstedt <marta.lofstedt> |
| Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
| Status: | CLOSED WORKSFORME | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
| Severity: | normal | ||
| Priority: | medium | CC: | intel-gfx-bugs |
| Version: | DRI git | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | ReadyForDev | ||
| i915 platform: | HSW | i915 features: | GEM/Other |
|
Description
Marta Löfstedt
2017-12-11 08:17:09 UTC
Yet another false positive. In i915_vma_revoke_mmap, the mapping is the device-local GTT mapping, which is barred from being used as a source for userptr -- because of this deadlock. We could overwrite the lockclass for the device local mapping, I think. Repeating my analysis from the mail thread: This looks real: https://www.spinics.net/lists/intel-gfx/msg150141.html In both cases of the circle we seem to hit exactly the same gtt/drm_device mapping locks. One way to break this is to make sure we do not call flush_workqueue on a range which isn't userptr-mapped (which automatically avoids gtt mmaps, since those are not allowed for userptr, or at least should). That option still has the classification problem, and I'm honestly not sure it's actually deadlock-free. Or we have to somehow get rid of the flush_work from the mmu_notifier callback entirely. Safest option, but I dunno how right now. Ok, I read the code some more, and the cancel_userptr work_struct trick used to hide the real locking dependencies i915_gem_userptr_mn_invalidate_range_start() from lockdep simply doesn't work anymore with the cross-release stuff. The queue_work(wq, work); ... flush_workqueue(wq); is a dead giveaway that we have the full locking dependencies of whatever runs in work. I'd say lockdep is correct here. (I still don't know how to fix this) Last seen CI_DRM_3486: 2017-12-09 / 186 runs ago |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.