Bug 103761 - [CI] igt@sw_sync@sync_multi_timeline_wait - WARNING: possible circular locking dependency detected
Summary: [CI] igt@sw_sync@sync_multi_timeline_wait - WARNING: possible circular lockin...
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: Other All
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-15 13:18 UTC by Marta Löfstedt
Modified: 2017-11-22 07:40 UTC (History)
1 user (show)

See Also:
i915 platform: GLK
i915 features:


Attachments

Description Marta Löfstedt 2017-11-15 13:18:05 UTC
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3348/shard-glkb3/igt@sw_sync@sync_multi_timeline_wait.html

NOTE, I just stumbled upon this, so our dmesg filtering is still not picking this up.

<7>[   34.528535] [IGT] sw_sync: starting subtest sync_multi_timeline_wait

<4>[   34.529127] ======================================================
<4>[   34.529131] WARNING: possible circular locking dependency detected
<4>[   34.529135] 4.14.0-CI-CI_DRM_3348+ #1 Not tainted
<4>[   34.529138] ------------------------------------------------------
<4>[   34.529142] sw_sync/1375 is trying to acquire lock:
<4>[   34.529145]  (&(&array->lock)->rlock){....}, at: [<ffffffff8165113c>] dma_fence_signal+0xcc/0x1f0
<4>[   34.529157] 
                  but task is already holding lock:
<4>[   34.529160]  (&(&obj->lock)->rlock){....}, at: [<ffffffff81654ffc>] sync_timeline_signal+0x4c/0x200
<4>[   34.529168] 
                  which lock already depends on the new lock.

<4>[   34.529172] 
                  the existing dependency chain (in reverse order) is:
<4>[   34.529176] 
                  -> #1 (&(&obj->lock)->rlock){....}:
<4>[   34.529185]        lock_acquire+0xb0/0x200
<4>[   34.529190]        _raw_spin_lock_irqsave+0x3d/0x60
<4>[   34.529194]        dma_fence_add_callback+0x42/0x220
<4>[   34.529199]        dma_fence_array_enable_signaling+0x4b/0xc0
<4>[   34.529203]        dma_fence_add_callback+0xa9/0x220
<4>[   34.529207]        sync_file_poll+0xa8/0xc0
<4>[   34.529212]        do_sys_poll+0x28b/0x5a0
<4>[   34.529216]        SyS_poll+0x62/0x110
<4>[   34.529219]        entry_SYSCALL_64_fastpath+0x1c/0xb1
<4>[   34.529222] 
                  -> #0 (&(&array->lock)->rlock){....}:
<4>[   34.529230]        __lock_acquire+0x1962/0x1b00
<4>[   34.529233]        lock_acquire+0xb0/0x200
<4>[   34.529237]        _raw_spin_lock_irqsave+0x3d/0x60
<4>[   34.529241]        dma_fence_signal+0xcc/0x1f0
<4>[   34.529244]        dma_fence_array_cb_func+0x34/0x40
<4>[   34.529249]        dma_fence_signal_locked+0x83/0x200
<4>[   34.529253]        sync_timeline_signal+0xcf/0x200
<4>[   34.529256]        sw_sync_ioctl+0x1db/0x340
<4>[   34.529260]        do_vfs_ioctl+0x94/0x670
<4>[   34.529264]        SyS_ioctl+0x41/0x70
<4>[   34.529267]        entry_SYSCALL_64_fastpath+0x1c/0xb1
<4>[   34.529270] 
                  other info that might help us debug this:

<4>[   34.529275]  Possible unsafe locking scenario:

<4>[   34.529279]        CPU0                    CPU1
<4>[   34.529282]        ----                    ----
<4>[   34.529285]   lock(&(&obj->lock)->rlock);
<4>[   34.529289]                                lock(&(&array->lock)->rlock);
<4>[   34.529293]                                lock(&(&obj->lock)->rlock);
<4>[   34.529298]   lock(&(&array->lock)->rlock);
<4>[   34.529302] 
                   *** DEADLOCK ***

<4>[   34.529306] 1 lock held by sw_sync/1375:
<4>[   34.529309]  #0:  (&(&obj->lock)->rlock){....}, at: [<ffffffff81654ffc>] sync_timeline_signal+0x4c/0x200
<4>[   34.529317] 
                  stack backtrace:
<4>[   34.529322] CPU: 1 PID: 1375 Comm: sw_sync Not tainted 4.14.0-CI-CI_DRM_3348+ #1
<4>[   34.529326] Hardware name: Intel Corp. Geminilake/GLK RVP1 DDR4 (05), BIOS GELKRVPA.X64.0062.B30.1708222146 08/22/2017
<4>[   34.529332] Call Trace:
<4>[   34.529336]  dump_stack+0x68/0x9f
<4>[   34.529341]  print_circular_bug.isra.18+0x1f6/0x2e0
<4>[   34.529345]  __lock_acquire+0x1962/0x1b00
<4>[   34.529351]  lock_acquire+0xb0/0x200
<4>[   34.529354]  ? lock_acquire+0xb0/0x200
<4>[   34.529358]  ? dma_fence_signal+0xcc/0x1f0
<4>[   34.529362]  _raw_spin_lock_irqsave+0x3d/0x60
<4>[   34.529366]  ? dma_fence_signal+0xcc/0x1f0
<4>[   34.529370]  dma_fence_signal+0xcc/0x1f0
<4>[   34.529374]  dma_fence_array_cb_func+0x34/0x40
<4>[   34.529378]  dma_fence_signal_locked+0x83/0x200
<4>[   34.529382]  sync_timeline_signal+0xcf/0x200
<4>[   34.529387]  sw_sync_ioctl+0x1db/0x340
<4>[   34.529391]  do_vfs_ioctl+0x94/0x670
<4>[   34.529395]  ? entry_SYSCALL_64_fastpath+0x5/0xb1
<4>[   34.529400]  ? __this_cpu_preempt_check+0x13/0x20
<4>[   34.529404]  ? trace_hardirqs_on_caller+0xe3/0x1b0
<4>[   34.529409]  SyS_ioctl+0x41/0x70
<4>[   34.529413]  entry_SYSCALL_64_fastpath+0x1c/0xb1
<4>[   34.529417] RIP: 0033:0x7f8d50358587
<4>[   34.529419] RSP: 002b:00007ffeb8e97a68 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
<4>[   34.529425] RAX: ffffffffffffffda RBX: ffffffff814920c3 RCX: 00007f8d50358587
<4>[   34.529429] RDX: 00007ffeb8e97aac RSI: 0000000040045701 RDI: 0000000000000005
<4>[   34.529433] RBP: ffffc90001bfff88 R08: 000055ecb273c3a0 R09: 0000000000000001
<4>[   34.529437] R10: 00007f8d5061bb58 R11: 0000000000000246 R12: 0000000000000003
<4>[   34.529441] R13: 0000000000000005 R14: 0000000040045701 R15: 000000000000000a
<4>[   34.529446]  ? __this_cpu_preempt_check+0x13/0x20
<7>[   34.529806] [IGT] sw_sync: exiting, ret=0
Comment 1 Chris Wilson 2017-11-15 13:22:21 UTC
https://patchwork.freedesktop.org/series/33799/
Comment 3 Chris Wilson 2017-11-21 21:08:03 UTC
commit 03e4e0a9e02cf703da331ff6cfd57d0be9bf5692
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Nov 14 16:27:19 2017 +0000

    dma-buf/fence: Fix lock inversion within dma-fence-array
Comment 4 Marta Löfstedt 2017-11-22 07:40:22 UTC
The fix was included from CI_DRM_3369.


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.