igt@gem_persistent_relocs*|igt@gem_pwrite@* - dmesg-warn - WARNING: possible circular locking dependency detected, acquire lock at: rcu_barrier, holding lock at: fs_reclaim_acquire.part
<6> [3028.129300] Console: switching to colour dummy device 80x25
<6> [3028.129409] [IGT] gem_persistent_relocs: executing
<6> [3028.155084] [IGT] gem_persistent_relocs: starting subtest forked-interruptible-faulting-reloc-thrashing
<5> [3028.175221] Setting dangerous option prefault_disable - tainting kernel
<5> [3028.179187] Setting dangerous option prefault_disable - tainting kernel
<5> [3031.895456] Setting dangerous option prefault_disable - tainting kernel
<5> [3031.904464] Setting dangerous option prefault_disable - tainting kernel
<4> [3032.683407]
<4> [3032.683416] ======================================================
<4> [3032.683420] WARNING: possible circular locking dependency detected
<4> [3032.683426] 5.4.0-rc8-CI-CI_DRM_7489+ #1 Tainted: G U
<4> [3032.683431] ------------------------------------------------------
<4> [3032.683435] gem_persistent_/10155 is trying to acquire lock:
<4> [3032.683440] ffffffff82248218 (rcu_state.barrier_mutex){+.+.}, at: rcu_barrier+0x23/0x190
<4> [3032.683453]
but task is already holding lock:
<4> [3032.683457] ffffffff82263a40 (fs_reclaim){+.+.}, at: fs_reclaim_acquire.part.117+0x0/0x30
<4> [3032.683466]
which lock already depends on the new lock.
<4> [3032.683471]
the existing dependency chain (in reverse order) is:
<4> [3032.683476]
-> #2 (fs_reclaim){+.+.}:
<4> [3032.683483] fs_reclaim_acquire.part.117+0x24/0x30
<4> [3032.683489] kmem_cache_alloc_trace+0x2a/0x2c0
<4> [3032.683495] intel_cpuc_prepare+0x37/0x1a0
<4> [3032.683502] cpuhp_invoke_callback+0x9b/0x9d0
<4> [3032.683507] _cpu_up+0xa2/0x140
<4> [3032.683511] do_cpu_up+0x61/0xa0
<4> [3032.683517] smp_init+0x57/0x96
<4> [3032.683522] kernel_init_freeable+0xac/0x1c7
<4> [3032.683528] kernel_init+0x5/0x100
<4> [3032.683533] ret_from_fork+0x24/0x50
<4> [3032.683537]
-> #1 (cpu_hotplug_lock.rw_sem){++++}:
<4> [3032.683545] cpus_read_lock+0x34/0xd0
<4> [3032.683549] rcu_barrier+0xaa/0x190
<4> [3032.683553] kernel_init+0x21/0x100
<4> [3032.683557] ret_from_fork+0x24/0x50
<4> [3032.683560]
-> #0 (rcu_state.barrier_mutex){+.+.}:
<4> [3032.683568] __lock_acquire+0x1328/0x15d0
<4> [3032.683572] lock_acquire+0xa7/0x1c0
<4> [3032.683577] __mutex_lock+0x9a/0x9d0
<4> [3032.683580] rcu_barrier+0x23/0x190
<4> [3032.683695] i915_gem_object_unbind+0x3a6/0x400 [i915]
<4> [3032.683777] i915_gem_shrink+0x297/0x5f0 [i915]
<4> [3032.683858] i915_gem_shrink_all+0x38/0x60 [i915]
<4> [3032.683931] i915_drop_caches_set+0x1f0/0x240 [i915]
<4> [3032.683938] simple_attr_write+0xb0/0xd0
<4> [3032.683945] full_proxy_write+0x51/0x80
<4> [3032.683950] vfs_write+0xb9/0x1d0
<4> [3032.683954] ksys_write+0x9f/0xe0
<4> [3032.683959] do_syscall_64+0x4f/0x210
<4> [3032.683963] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4> [3032.683967]
other info that might help us debug this:
<4> [3032.683972] Chain exists of:
rcu_state.barrier_mutex --> cpu_hotplug_lock.rw_sem --> fs_reclaim
<4> [3032.683981] Possible unsafe locking scenario:
<4> [3032.683986] CPU0 CPU1
<4> [3032.683990] ---- ----
<4> [3032.683993] lock(fs_reclaim);
<4> [3032.683996] lock(cpu_hotplug_lock.rw_sem);
<4> [3032.684001] lock(fs_reclaim);
<4> [3032.684006] lock(rcu_state.barrier_mutex);
<4> [3032.684009]
*** DEADLOCK ***https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5335/shard-tglb5/igt@gem_pwrite@big-gtt-forwards.html
<4> [430.243250] ======================================================
<4> [430.243252] WARNING: possible circular locking dependency detected
<4> [430.243259] 5.4.0-rc8-CI-CI_DRM_7502+ #1 Tainted: G U
<4> [430.243261] ------------------------------------------------------
<4> [430.243263] gem_pwrite/2270 is trying to acquire lock:
<4> [430.243266] ffffffff82248218 (rcu_state.barrier_mutex){+.+.}, at: rcu_barrier+0x23/0x190
<4> [430.243273]
but task is already holding lock:
<4> [430.243275] ffffffff82263a40 (fs_reclaim){+.+.}, at: fs_reclaim_acquire.part.117+0x0/0x30
<4> [430.243281]
which lock already depends on the new lock.
<4> [430.243283]
the existing dependency chain (in reverse order) is:
<4> [430.243285]
-> #2 (fs_reclaim){+.+.}:
<4> [430.243288] fs_reclaim_acquire.part.117+0x24/0x30
<4> [430.243293] kmem_cache_alloc_trace+0x2a/0x2c0
<4> [430.243297] intel_cpuc_prepare+0x37/0x1a0
<4> [430.243301] cpuhp_invoke_callback+0x9b/0x9d0
<4> [430.243304] _cpu_up+0xa2/0x140
<4> [430.243306] do_cpu_up+0x61/0xa0
<4> [430.243310] smp_init+0x57/0x96
<4> [430.243314] kernel_init_freeable+0xac/0x1c7
<4> [430.243318] kernel_init+0x5/0x100
<4> [430.243322] ret_from_fork+0x24/0x50
<4> [430.243323]
-> #1 (cpu_hotplug_lock.rw_sem){++++}:
<4> [430.243327] cpus_read_lock+0x34/0xd0
<4> [430.243329] rcu_barrier+0xaa/0x190
<4> [430.243331] kernel_init+0x21/0x100
<4> [430.243333] ret_from_fork+0x24/0x50
<4> [430.243334]
-> #0 (rcu_state.barrier_mutex){+.+.}:
<4> [430.243338] __lock_acquire+0x1328/0x15d0
<4> [430.243340] lock_acquire+0xa7/0x1c0
<4> [430.243343] __mutex_lock+0x9a/0x9d0
<4> [430.243344] rcu_barrier+0x23/0x190
<4> [430.243408] i915_gem_object_unbind+0x264/0x3d0 [i915]
<4> [430.243446] i915_gem_shrink+0x297/0x5f0 [i915]
<4> [430.243484] i915_gem_shrink_all+0x38/0x60 [i915]
<4> [430.243519] i915_drop_caches_set+0x1f0/0x240 [i915]
<4> [430.243523] simple_attr_write+0xb0/0xd0
<4> [430.243527] full_proxy_write+0x51/0x80
<4> [430.243538] vfs_write+0xb9/0x1d0
<4> [430.243540] ksys_write+0x9f/0xe0
<4> [430.243542] do_syscall_64+0x4f/0x210
<4> [430.243544] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4> [430.243550]
other info that might help us debug this:
<4> [430.243559] Chain exists of:
rcu_state.barrier_mutex --> cpu_hotplug_lock.rw_sem --> fs_reclaim
<4> [430.243595] Possible unsafe locking scenario:
<4> [430.243600] CPU0 CPU1
<4> [430.243603] ---- ----
<4> [430.243609] lock(fs_reclaim);
<4> [430.243613] lock(cpu_hotplug_lock.rw_sem);
<4> [430.243620] lock(fs_reclaim);
<4> [430.243623] lock(rcu_state.barrier_mutex);
<4> [430.243626]
*** DEADLOCK ***Edited by LAKSHMINARAYANA VUDUM