Bug 111783

Summary:	[CI][SHARDS]igt@gem_persistent_relocs@forked-interruptible-thrashing\|igt@gem_pipe_control_store_loop@reused-buffer - dmesg-warn - WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
Product:	DRI	Reporter:	Lakshmi <lakshminarayana.vudum>
Component:	DRM/Intel	Assignee:	Intel GFX Bugs mailing list <intel-gfx-bugs>
Status:	RESOLVED DUPLICATE	QA Contact:	Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity:	not set
Priority:	not set	CC:	intel-gfx-bugs
Version:	DRI git
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:	BYT, GLK	i915 features:	GEM/Other

Description Lakshmi 2019-09-23 13:27:36 UTC

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_373/fi-byt-j1900/igt@gem_persistent_relocs@forked-interruptible-thrashing.html

	
<6> [363.115255] Console: switching to colour dummy device 80x25
<6> [363.115518] [IGT] gem_persistent_relocs: executing
<6> [363.163854] [IGT] gem_persistent_relocs: starting subtest forked-interruptible-thrashing
<4> [363.415108] 
<4> [363.415118] =====================================================
<4> [363.415127] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
<4> [363.415136] 5.3.0-g7ca2b123ae99-drmtip_373+ #1 Tainted: G     U           
<4> [363.415144] -----------------------------------------------------
<4> [363.415152] gem_persistent_/1229 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
<4> [363.415162] 00000000fd73e298 (&(&lock->wait_lock)->rlock){+.+.}, at: __mutex_unlock_slowpath+0x18e/0x2b0
<4> [363.415180] 
and this task is already holding:
<4> [363.415187] 00000000a68032b3 (&(&timelines->lock)->rlock){-...}, at: i915_retire_requests+0x14c/0x2e0 [i915]
<4> [363.415311] which would create a new lock dependency:
<4> [363.415318]  (&(&timelines->lock)->rlock){-...} -> (&(&lock->wait_lock)->rlock){+.+.}
<4> [363.415330] 
but this new dependency connects a HARDIRQ-irq-safe lock:
<4> [363.415338]  (&(&timelines->lock)->rlock){-...}
<4> [363.415340] 
... which became HARDIRQ-irq-safe at:
<4> [363.415354]   lock_acquire+0xa6/0x1c0
<4> [363.415363]   _raw_spin_lock_irqsave+0x33/0x50
<4> [363.415470]   intel_timeline_enter+0x64/0x150 [i915]
<4> [363.415566]   __engine_park+0x9d/0x320 [i915]
<4> [363.415657]   ____intel_wakeref_put_last+0x1c/0x70 [i915]
<4> [363.415746]   i915_sample+0x2ed/0x310 [i915]
<4> [363.415755]   __hrtimer_run_queues+0x11e/0x4b0
<4> [363.415762]   hrtimer_interrupt+0xea/0x250
<4> [363.415770]   smp_apic_timer_interrupt+0x96/0x280
<4> [363.415778]   apic_timer_interrupt+0xf/0x20
<4> [363.415786]   cpuidle_enter_state+0xae/0x450
<4> [363.415793]   cpuidle_enter+0x24/0x40
<4> [363.415801]   do_idle+0x1f3/0x260
<4> [363.415807]   cpu_startup_entry+0x14/0x20
<4> [363.415816]   start_kernel+0x50d/0x52f
<4> [363.415823]   secondary_startup_64+0xa4/0xb0
<4> [363.415829] 
to a HARDIRQ-irq-unsafe lock:
<4> [363.415836]  (&(&lock->wait_lock)->rlock){+.+.}
<4> [363.415838] 
... which became HARDIRQ-irq-unsafe at:
<4> [363.415851] ...
<4> [363.415853]   lock_acquire+0xa6/0x1c0
<4> [363.415863]   _raw_spin_lock+0x2a/0x40
<4> [363.415870]   __mutex_lock+0x18a/0x9b0
<4> [363.415972]   __i915_gem_free_objects+0x7b/0x4b0 [i915]
<4> [363.415981]   process_one_work+0x245/0x610
<4> [363.415988]   worker_thread+0x37/0x380
<4> [363.415996]   kthread+0x119/0x130
<4> [363.416002]   ret_from_fork+0x3a/0x50
<4> [363.416008] 
other info that might help us debug this:

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

<4> [363.416026]        CPU0                    CPU1
<4> [363.416032]        ----                    ----
<4> [363.416037]   lock(&(&lock->wait_lock)->rlock);
<4> [363.416044]                                local_irq_disable();
<4> [363.416051]                                lock(&(&timelines->lock)->rlock);
<4> [363.416060]                                lock(&(&lock->wait_lock)->rlock);
<4> [363.416069]   <Interrupt>
<4> [363.416073]     lock(&(&timelines->lock)->rlock);
<4> [363.416080] 
 *** DEADLOCK ***

Comment 1 Lakshmi 2019-09-23 13:28:26 UTC

https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5194/shard-glk1/igt@gem_pipe_control_store_loop@reused-buffer.html

<6> [2763.705978] Console: switching to colour dummy device 80x25
<6> [2763.706073] [IGT] gem_pipe_control_store_loop: executing
<6> [2763.719176] [IGT] gem_pipe_control_store_loop: starting subtest reused-buffer
<4> [2799.682286] 
<4> [2799.682295] =====================================================
<4> [2799.682300] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
<4> [2799.682305] 5.3.0-CI-CI_DRM_6927+ #1 Tainted: G     U           
<4> [2799.682309] -----------------------------------------------------
<4> [2799.682313] kworker/u8:15/3290 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
<4> [2799.682318] ffff888273cd9e08 (&(&lock->wait_lock)->rlock){+.+.}, at: __mutex_unlock_slowpath+0x18e/0x2b0
<4> [2799.682331] 
and this task is already holding:
<4> [2799.682335] ffff88825db5c320 (&(&timelines->lock)->rlock){-...}, at: i915_retire_requests+0x14c/0x2e0 [i915]
<4> [2799.682435] which would create a new lock dependency:
<4> [2799.682438]  (&(&timelines->lock)->rlock){-...} -> (&(&lock->wait_lock)->rlock){+.+.}
<4> [2799.682444] 
but this new dependency connects a HARDIRQ-irq-safe lock:
<4> [2799.682448]  (&(&timelines->lock)->rlock){-...}
<4> [2799.682449] 
... which became HARDIRQ-irq-safe at:
<4> [2799.682459]   lock_acquire+0xa6/0x1c0
<4> [2799.682464]   _raw_spin_lock_irqsave+0x33/0x50
<4> [2799.682527]   intel_timeline_enter+0x64/0x150 [i915]
<4> [2799.682588]   __engine_park+0xa9/0x380 [i915]
<4> [2799.682648]   ____intel_wakeref_put_last+0x1c/0x70 [i915]
<4> [2799.682707]   i915_sample+0x2ed/0x310 [i915]
<4> [2799.682712]   __hrtimer_run_queues+0x11e/0x4b0
<4> [2799.682717]   hrtimer_interrupt+0xea/0x250
<4> [2799.682722]   smp_apic_timer_interrupt+0x96/0x280
<4> [2799.682726]   apic_timer_interrupt+0xf/0x20
<4> [2799.682730]   mutex_spin_on_owner+0x81/0x140
<4> [2799.682733]   __mutex_lock+0x5f9/0x9b0
<4> [2799.682796]   __i915_gem_free_objects+0x7b/0x4b0 [i915]
<4> [2799.682802]   process_one_work+0x245/0x610
<4> [2799.682805]   worker_thread+0x37/0x380
<4> [2799.682810]   kthread+0x119/0x130
<4> [2799.682813]   ret_from_fork+0x24/0x50
<4> [2799.682816] 
to a HARDIRQ-irq-unsafe lock:
<4> [2799.682820]  (&(&lock->wait_lock)->rlock){+.+.}
<4> [2799.682821] 
... which became HARDIRQ-irq-unsafe at:
<4> [2799.682827] ...
<4> [2799.682829]   lock_acquire+0xa6/0x1c0
<4> [2799.682834]   _raw_spin_lock+0x2a/0x40
<4> [2799.682837]   __mutex_lock+0x18a/0x9b0
<4> [2799.682842]   pipe_wait+0x8f/0xc0
<4> [2799.682845]   pipe_read+0x235/0x310
<4> [2799.682849]   new_sync_read+0x106/0x1a0
<4> [2799.682853]   vfs_read+0x9e/0x160
<4> [2799.682856]   ksys_read+0x8f/0xe0
<4> [2799.682860]   do_syscall_64+0x4f/0x210
<4> [2799.682864]   entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4> [2799.682867] 
other info that might help us debug this:

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

<4> [2799.682877]        CPU0                    CPU1
<4> [2799.682880]        ----                    ----
<4> [2799.682883]   lock(&(&lock->wait_lock)->rlock);
<4> [2799.682887]                                local_irq_disable();
<4> [2799.682890]                                lock(&(&timelines->lock)->rlock);
<4> [2799.682895]                                lock(&(&lock->wait_lock)->rlock);
<4> [2799.682899]   <Interrupt>
<4> [2799.682901]     lock(&(&timelines->lock)->rlock);
<4> [2799.682905] 
 *** DEADLOCK ***

Comment 2 CI Bug Log 2019-09-23 13:29:04 UTC

The CI Bug Log issue associated to this bug has been updated.

### New filters associated

* BYT GLK: igt@gem_persistent_relocs@forked-interruptible-thrashing|igt@gem_pipe_control_store_loop@reused-buffer - dmesg-warn - WARNING: HARDIRQ-safe -&gt; HARDIRQ-unsafe lock order detected
  - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_373/fi-byt-j1900/igt@gem_persistent_relocs@forked-interruptible-thrashing.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5194/shard-glk1/igt@gem_pipe_control_store_loop@reused-buffer.html

Comment 3 Chris Wilson 2019-09-23 13:32:53 UTC

Same perf lockdep, just delayed until another test completed the loop.

*** This bug has been marked as a duplicate of bug 111626 ***

Comment 4 CI Bug Log 2019-09-27 12:50:35 UTC

A CI Bug Log filter associated to this bug has been updated:

{- BYT GLK: igt@gem_persistent_relocs@forked-interruptible-thrashing|igt@gem_pipe_control_store_loop@reused-buffer - dmesg-warn - WARNING: HARDIRQ-safe -&gt; HARDIRQ-unsafe lock order detected -}
{+ BYT SKL GLK: igt@gem_persistent_relocs@forked-interruptible-thrashing|igt@gem_pipe_control_store_loop@reused-buffe|igt@i915_pm_rps@waitboost - dmesg-warn - WARNING: HARDIRQ-safe -&gt; HARDIRQ-unsafe lock order detected +}

New failures caught by the filter:

  * https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5204/shard-skl2/igt@i915_pm_rps@waitboost.html

Comment 5 CI Bug Log 2019-09-30 09:20:45 UTC

A CI Bug Log filter associated to this bug has been updated:

{- BYT SKL GLK: igt@gem_persistent_relocs@forked-interruptible-thrashing|igt@gem_pipe_control_store_loop@reused-buffe|igt@i915_pm_rps@waitboost - dmesg-warn - WARNING: HARDIRQ-safe -&gt; HARDIRQ-unsafe lock order detected -}
{+ BYT APL SKL GLK: igt@gem_persistent_relocs@forked-interruptible-thrashing|igt@gem_pipe_control_store_loop@reused-buffe|igt@i915_pm_rps@waitboost - dmesg-warn - WARNING: HARDIRQ-safe -&gt; HARDIRQ-unsafe lock order detected +}

New failures caught by the filter:

  * https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6967/shard-apl7/igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrash-inactive.html

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.