Bug 1410879 - possible circular locking dependency detected: Xorg is trying to acquire lock but task is already holding lock
Summary: possible circular locking dependency detected: Xorg is trying to acquire lock...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nouveau
Version: 27
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ben Skeggs
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-06 17:03 UTC by Jan Pokorný [poki]
Modified: 2018-11-30 17:57 UTC (History)
25 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-30 17:57:27 UTC
Type: Bug


Attachments (Terms of Use)

Description Jan Pokorný [poki] 2017-01-06 17:03:50 UTC
Found this in dmesg output:

[ 1429.194978] ======================================================
[ 1429.194979] [ INFO: possible circular locking dependency detected ]
[ 1429.194980] 4.10.0-0.rc2.git2.1.fc26.x86_64 #1 Tainted: G            E  
[ 1429.194981] -------------------------------------------------------
[ 1429.194982] Xorg/4621 is trying to acquire lock:
[ 1429.194982]  (&dev->struct_mutex){+.+.+.}, at: [<ffffffffc0194eca>] drm_gem_object_unreference_unlocked+0xa/0xe0 [drm]
[ 1429.194991] 
               but task is already holding lock:
[ 1429.194992]  (reservation_ww_class_mutex){+.+.+.}, at: [<ffffffffc05223d9>] validate_init.isra.8+0x219/0x7f0 [nouveau]
[ 1429.195014] 
               which lock already depends on the new lock.

[ 1429.195015] 
               the existing dependency chain (in reverse order) is:
[ 1429.195016] 
               -> #1 (reservation_ww_class_mutex){+.+.+.}:
[ 1429.195018]        
[ 1429.195020] [<ffffffff95118906>] lock_acquire+0xf6/0x1f0
[ 1429.195021]        
[ 1429.195023] [<ffffffff95954b89>] mutex_lock_nested+0x89/0x6e0
[ 1429.195023]        
[ 1429.195037] [<ffffffffc0334ae6>] i915_gem_do_execbuffer.isra.37+0x1936/0x1da0 [i915]
[ 1429.195038]        
[ 1429.195048] [<ffffffffc033538f>] i915_gem_execbuffer2+0xcf/0x260 [i915]
[ 1429.195048]        
[ 1429.195054] [<ffffffffc01962aa>] drm_ioctl+0x37a/0x4e0 [drm]
[ 1429.195054]        
[ 1429.195056] [<ffffffff952d6723>] do_vfs_ioctl+0xa3/0x740
[ 1429.195057]        
[ 1429.195058] [<ffffffff952d6e39>] SyS_ioctl+0x79/0x90
[ 1429.195059]        
[ 1429.195061] [<ffffffff95959fc1>] entry_SYSCALL_64_fastpath+0x1f/0xc2
[ 1429.195061] 
               -> #0 (&dev->struct_mutex){+.+.+.}:
[ 1429.195063]        
[ 1429.195064] [<ffffffff95118315>] __lock_acquire+0x10e5/0x1270
[ 1429.195065]        
[ 1429.195066] [<ffffffff95118906>] lock_acquire+0xf6/0x1f0
[ 1429.195067]        
[ 1429.195071] [<ffffffffc0194f05>] drm_gem_object_unreference_unlocked+0x45/0xe0 [drm]
[ 1429.195072]        
[ 1429.195089] [<ffffffffc0522156>] validate_fini_no_ticket+0xb6/0x120 [nouveau]
[ 1429.195090]        
[ 1429.195105] [<ffffffffc05234e2>] nouveau_gem_ioctl_pushbuf+0x312/0x10c0 [nouveau]
[ 1429.195106]        
[ 1429.195110] [<ffffffffc01962aa>] drm_ioctl+0x37a/0x4e0 [drm]
[ 1429.195111]        
[ 1429.195126] [<ffffffffc0519be4>] nouveau_drm_ioctl+0x74/0xc0 [nouveau]
[ 1429.195127]        
[ 1429.195128] [<ffffffff952d6723>] do_vfs_ioctl+0xa3/0x740
[ 1429.195129]        
[ 1429.195130] [<ffffffff952d6e39>] SyS_ioctl+0x79/0x90
[ 1429.195130]        
[ 1429.195132] [<ffffffff95959fc1>] entry_SYSCALL_64_fastpath+0x1f/0xc2
[ 1429.195133] 
               other info that might help us debug this:

[ 1429.195134]  Possible unsafe locking scenario:

[ 1429.195135]        CPU0                    CPU1
[ 1429.195135]        ----                    ----
[ 1429.195136]   lock(reservation_ww_class_mutex);
[ 1429.195137]                                lock(&dev->struct_mutex);
[ 1429.195138]                                lock(reservation_ww_class_mutex);
[ 1429.195139]   lock(&dev->struct_mutex);
[ 1429.195141] 
                *** DEADLOCK ***

[ 1429.195143] 3 locks held by Xorg/4621:
[ 1429.195143]  #0:  (&cli->mutex){+.+.+.}, at: [<ffffffffc0538c60>] nouveau_abi16_get+0x30/0x70 [nouveau]
[ 1429.195160]  #1:  (reservation_ww_class_acquire){+.+.+.}, at: [<ffffffffc05235d5>] nouveau_gem_ioctl_pushbuf+0x405/0x10c0 [nouveau]
[ 1429.195175]  #2:  (reservation_ww_class_mutex){+.+.+.}, at: [<ffffffffc05223d9>] validate_init.isra.8+0x219/0x7f0 [nouveau]
[ 1429.195190] 
               stack backtrace:
[ 1429.195192] CPU: 2 PID: 4621 Comm: Xorg Tainted: G            E   4.10.0-0.rc2.git2.1.fc26.x86_64 #1
[ 1429.195193] Hardware name: LENOVO 20FXS0BB14/20FXS0BB14, BIOS R07ET63W (2.03 ) 03/15/2016
[ 1429.195193] Call Trace:
[ 1429.195195]  dump_stack+0x86/0xc3
[ 1429.195197]  print_circular_bug+0x1be/0x210
[ 1429.195199]  __lock_acquire+0x10e5/0x1270
[ 1429.195200]  lock_acquire+0xf6/0x1f0
[ 1429.195205]  ? drm_gem_object_unreference_unlocked+0xa/0xe0 [drm]
[ 1429.195210]  drm_gem_object_unreference_unlocked+0x45/0xe0 [drm]
[ 1429.195214]  ? drm_gem_object_unreference_unlocked+0xa/0xe0 [drm]
[ 1429.195228]  validate_fini_no_ticket+0xb6/0x120 [nouveau]
[ 1429.195242]  nouveau_gem_ioctl_pushbuf+0x312/0x10c0 [nouveau]
[ 1429.195247]  drm_ioctl+0x37a/0x4e0 [drm]
[ 1429.195249]  ? sched_clock_cpu+0xa7/0xc0
[ 1429.195262]  ? nouveau_gem_ioctl_new+0x150/0x150 [nouveau]
[ 1429.195264]  ? trace_hardirqs_on+0xd/0x10
[ 1429.195278]  nouveau_drm_ioctl+0x74/0xc0 [nouveau]
[ 1429.195280]  do_vfs_ioctl+0xa3/0x740
[ 1429.195281]  ? up_read+0x1f/0x40
[ 1429.195282]  SyS_ioctl+0x79/0x90
[ 1429.195284]  entry_SYSCALL_64_fastpath+0x1f/0xc2
[ 1429.195285] RIP: 0033:0x7fd63f1a7757
[ 1429.195286] RSP: 002b:00007ffe53bbe7e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 1429.195287] RAX: ffffffffffffffda RBX: 00000000027e3c10 RCX: 00007fd63f1a7757
[ 1429.195288] RDX: 00007ffe53bbe850 RSI: 00000000c0406481 RDI: 000000000000000f
[ 1429.195289] RBP: 00000000027e3cd8 R08: 0000000000000000 R09: 00000000027f8b00
[ 1429.195290] R10: 00000000027f8710 R11: 0000000000000246 R12: 00000000027e3370
[ 1429.195290] R13: 00000000027e3cd0 R14: 00000000027e3680 R15: 00000000ffffffea


My HW: Lenovo T460p
> 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06)
> 02:00.0 3D controller: NVIDIA Corporation GM108M [GeForce 940MX] (rev a2)

$ rpm -qa | grep -e 'kernel-[0-9]' -e xorg-
> xorg-x11-utils-7.5-21.fc24.x86_64
> xorg-x11-server-Xwayland-1.19.0-3.fc26.x86_64
> xorg-x11-server-utils-7.7-20.fc26.x86_64
> kernel-4.10.0-0.rc2.git0.2.fc26.x86_64
> xorg-x11-xkb-utils-7.7-17.fc24.x86_64
> xorg-x11-drv-intel-2.99.917-26.20160929.fc26.x86_64
> kernel-4.10.0-0.rc2.git2.1.fc26.x86_64
> xorg-x11-xauth-1.0.9-5.fc24.x86_64
> xorg-x11-server-Xorg-1.19.0-3.fc26.x86_64
> xorg-x11-drv-nouveau-1.0.13-1.fc26.x86_64
> xorg-x11-font-utils-7.5-32.fc26.x86_64
> xorg-x11-resutils-7.5-13.fc24.x86_64
> xorg-x11-server-common-1.19.0-3.fc26.x86_64
> xorg-x11-xinit-1.3.4-13.fc26.x86_64
> xorg-x11-drv-evdev-2.10.4-1.fc26.x86_64
> xorg-x11-fonts-ISO8859-1-100dpi-7.5-16.fc24.noarch

I am using sway WM if it can be relevant:
> sway-0.11-4.fc26.x86_64


Let me know if you need any additional info, I'll keep an eye on possible recidivism.
I haven't seen this before (few past hours actually), perhaps it may be attributed either
to switching to updated kernel (both version stated) or to switching from awesome/X11
to sway/Wayland.

Comment 1 Fedora End Of Life 2017-02-28 10:54:09 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Comment 2 Pavel Roskin 2017-09-26 20:52:48 UTC
I can reproduce this bug reliably on up-to-date Fedora 27. The bug happens with the kernel 4.13.3-300.fc27.x86_64. It doesn't happen with the self-compiled Linux 4.14-rc1 or 4.14-rc2.

My system is a completely up-to-date Fedora 27 with updates and updates-testing repositories installed. I ran "dnf install 'Fedora Workstation'" is install all standard components. GNOME is used, no other desktop environments are installed. The system is Dell Precision 7510 with a dock. Two monitors, a keyboard and a mouse are connected to the dock. The laptop has Intel graphics for the internal monitor and NVIDIA for the external monitors. No non-free drivers are used.

======================================================
WARNING: possible circular locking dependency detected
4.13.3-300.fc27.x86_64 #1 Not tainted
------------------------------------------------------
Xorg/1032 is trying to acquire lock:
 (&dev->struct_mutex){+.+.+.}, at: [<ffffffffc03c4dfa>] drm_gem_object_put_unlocked+0xa/0xb0 [drm]

but task is already holding lock:
 (reservation_ww_class_mutex){+.+.+.}, at: [<ffffffffc04cccc2>] validate_init.isra.5+0x202/0x740 [nouveau]

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (reservation_ww_class_mutex){+.+.+.}:
       lock_acquire+0xa3/0x1f0
       __ww_mutex_lock.constprop.9+0xa1/0x10c0
       ww_mutex_lock+0x5e/0x70
       i915_gem_object_set_tiling+0x118/0x330 [i915]
       i915_gem_set_tiling_ioctl+0x1b4/0x350 [i915]
       drm_ioctl_kernel+0x5d/0xb0 [drm]
       drm_ioctl+0x31b/0x3d0 [drm]
       do_vfs_ioctl+0xa6/0x6c0
       SyS_ioctl+0x79/0x90
       entry_SYSCALL_64_fastpath+0x1f/0xbe

-> #0 (&dev->struct_mutex){+.+.+.}:
       __lock_acquire+0x1367/0x13b0
       lock_acquire+0xa3/0x1f0
       drm_gem_object_put_unlocked+0x3d/0xb0 [drm]
       validate_fini_no_ticket+0xf5/0x130 [nouveau]
       nouveau_gem_ioctl_pushbuf+0x65f/0x10f0 [nouveau]
       drm_ioctl_kernel+0x5d/0xb0 [drm]
       drm_ioctl+0x31b/0x3d0 [drm]
       nouveau_drm_ioctl+0x72/0xc0 [nouveau]
       do_vfs_ioctl+0xa6/0x6c0
       SyS_ioctl+0x79/0x90
       entry_SYSCALL_64_fastpath+0x1f/0xbe

other info that might help us debug this:
 Possible unsafe locking scenario:
       CPU0                    CPU1
       ----                    ----
  lock(reservation_ww_class_mutex);
                               lock(&dev->struct_mutex);
                               lock(reservation_ww_class_mutex);
  lock(&dev->struct_mutex);

 *** DEADLOCK ***
3 locks held by Xorg/1032:
 #0:  (&cli->mutex){+.+.+.}, at: [<ffffffffc04e3083>] nouveau_abi16_get+0x33/0x70 [nouveau]
 #1:  (reservation_ww_class_acquire){+.+.+.}, at: [<ffffffffc04cdc50>] nouveau_gem_ioctl_pushbuf+0x2c0/0x10f0 [nouveau]
 #2:  (reservation_ww_class_mutex){+.+.+.}, at: [<ffffffffc04cccc2>] validate_init.isra.5+0x202/0x740 [nouveau]

stack backtrace:
CPU: 7 PID: 1032 Comm: Xorg Not tainted 4.13.3-300.fc27.x86_64 #1
Hardware name: Dell Inc. Precision 7510/0692Y5, BIOS 1.12.4 05/12/2017
Call Trace:
 dump_stack+0x8e/0xd6
 print_circular_bug+0x1b6/0x210
 __lock_acquire+0x1367/0x13b0
 ? find_held_lock+0x3c/0xb0
 lock_acquire+0xa3/0x1f0
 ? lock_acquire+0xa3/0x1f0
 ? drm_gem_object_put_unlocked+0xa/0xb0 [drm]
 ? __mutex_unlock_slowpath+0x52/0x2f0
 drm_gem_object_put_unlocked+0x3d/0xb0 [drm]
 ? drm_gem_object_put_unlocked+0xa/0xb0 [drm]
 validate_fini_no_ticket+0xf5/0x130 [nouveau]
 nouveau_gem_ioctl_pushbuf+0x65f/0x10f0 [nouveau]
 ? nouveau_gem_ioctl_new+0x140/0x140 [nouveau]
 drm_ioctl_kernel+0x5d/0xb0 [drm]
 ? drm_ioctl_kernel+0x5d/0xb0 [drm]
 drm_ioctl+0x31b/0x3d0 [drm]
 ? nouveau_gem_ioctl_new+0x140/0x140 [nouveau]
 ? trace_hardirqs_on+0xd/0x10
 nouveau_drm_ioctl+0x72/0xc0 [nouveau]
 do_vfs_ioctl+0xa6/0x6c0
 SyS_ioctl+0x79/0x90
 entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x7f20d037f0d7
RSP: 002b:00007ffd3b9b7998 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000e4a3d0 RCX: 00007f20d037f0d7
RDX: 00007ffd3b9b7a00 RSI: 00000000c0406481 RDI: 0000000000000010
RBP: 0000000000e41670 R08: 0000000000000000 R09: 0000000000e42400
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000e417b0
R13: 0000000000e41da0 R14: 0000000000e4a3d0 R15: 0000000000e41da0

Comment 3 Laura Abbott 2017-09-27 17:48:37 UTC
Oh this is fun, both i915 and nouveau are involved here. This is probably best reported upstream at https://bugs.freedesktop.org/ . I'm going to move the component to the nouveau graphics package for better tracking in the meantime.

Comment 4 Ben Cotton 2018-11-27 18:25:34 UTC
This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 5 Ben Cotton 2018-11-30 17:57:27 UTC
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.