Bug 112153

https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7186/shard-apl8/igt@gem_busy@close-race.html
<4> [1776.577169] =====================================================
<4> [1776.577176] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
<4> [1776.577184] 5.4.0-rc4-CI-CI_DRM_7186+ #1 Tainted: G     U           
<4> [1776.577190] -----------------------------------------------------
<4> [1776.577197] kworker/3:4/1244 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
<4> [1776.577205] ffff888276ad5030 (&(&lock->wait_lock)->rlock){+.+.}, at: __mutex_unlock_slowpath+0x18e/0x2b0
<4> [1776.577222] 
and this task is already holding:
<4> [1776.577228] ffff88825508c2c8 (&(&timelines->lock)->rlock){-...}, at: intel_gt_retire_requests_timeout+0x180/0x540 [i915]
<4> [1776.577350] which would create a new lock dependency:
<4> [1776.577355]  (&(&timelines->lock)->rlock){-...} -> (&(&lock->wait_lock)->rlock){+.+.}
<4> [1776.577365] 
but this new dependency connects a HARDIRQ-irq-safe lock:
<4> [1776.577372]  (&(&timelines->lock)->rlock){-...}
<4> [1776.577374] 
... which became HARDIRQ-irq-safe at:
<4> [1776.577387]   lock_acquire+0xa7/0x1c0
<4> [1776.577394]   _raw_spin_lock_irqsave+0x33/0x50
<4> [1776.577488]   intel_timeline_enter+0x64/0x150 [i915]
<4> [1776.577576]   __engine_park+0x1ef/0x420 [i915]
<4> [1776.577660]   ____intel_wakeref_put_last+0x1c/0x70 [i915]
<4> [1776.577747]   i915_sample+0x2de/0x300 [i915]
<4> [1776.577754]   __hrtimer_run_queues+0x121/0x4a0
<4> [1776.577760]   hrtimer_interrupt+0xea/0x250
<4> [1776.577766]   smp_apic_timer_interrupt+0x96/0x280
<4> [1776.577772]   apic_timer_interrupt+0xf/0x20
<4> [1776.577778]   lock_release+0x17d/0x2a0
<4> [1776.577784]   _raw_spin_unlock+0x17/0x40
<4> [1776.577882]   release_pd_entry+0x67/0x130 [i915]
<4> [1776.577981]   __gen8_ppgtt_clear+0x20b/0x550 [i915]
<4> [1776.578080]   __gen8_ppgtt_clear+0x2d9/0x550 [i915]
<4> [1776.578181]   __i915_vma_unbind.part.39+0xb5/0x460 [i915]
<4> [1776.578283]   i915_vma_destroy+0x105/0x1e0 [i915]
<4> [1776.578378]   __i915_gem_free_objects+0x213/0x3e0 [i915]
<4> [1776.578386]   process_one_work+0x26a/0x620
<4> [1776.578391]   worker_thread+0x37/0x380
<4> [1776.578397]   kthread+0x119/0x130
<4> [1776.578403]   ret_from_fork+0x3a/0x50
<4> [1776.578408] 
to a HARDIRQ-irq-unsafe lock:
<4> [1776.578414]  (&(&lock->wait_lock)->rlock){+.+.}
<4> [1776.578415] 
... which became HARDIRQ-irq-unsafe at:
<4> [1776.578425] ...
<4> [1776.578428]   lock_acquire+0xa7/0x1c0
<4> [1776.578436]   _raw_spin_lock+0x2a/0x40
<4> [1776.578442]   __mutex_lock+0x198/0x9d0
<4> [1776.578449]   pipe_wait+0x8f/0xc0
<4> [1776.578454]   pipe_read+0x235/0x310
<4> [1776.578460]   new_sync_read+0x10f/0x1a0
<4> [1776.578465]   vfs_read+0x96/0x160
<4> [1776.578470]   ksys_read+0x9f/0xe0
<4> [1776.578477]   do_syscall_64+0x4f/0x210
<4> [1776.578483]   entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4> [1776.578489] 
other info that might help us debug this:

<4> [1776.578497]  Possible interrupt unsafe locking scenario:

<4> [1776.578503]        CPU0                    CPU1
<4> [1776.578508]        ----                    ----
<4> [1776.578513]   lock(&(&lock->wait_lock)->rlock);
<4> [1776.578519]                                local_irq_disable();
<4> [1776.578524]                                lock(&(&timelines->lock)->rlock);
<4> [1776.578531]                                lock(&(&lock->wait_lock)->rlock);
<4> [1776.578539]   <Interrupt>
<4> [1776.578542]     lock(&(&timelines->lock)->rlock);
<4> [1776.578548]