Possible circular locking dependency (3.3-rc2)
Felipe Balbi
balbi at ti.com
Wed Feb 8 07:41:48 EST 2012
Hi guys,
I have just triggered the folllowing:
[ 84.860321] ======================================================
[ 84.860321] [ INFO: possible circular locking dependency detected ]
[ 84.860321] 3.3.0-rc2-00026-ge4e8a39 #474 Not tainted
[ 84.860321] -------------------------------------------------------
[ 84.860321] bash/949 is trying to acquire lock:
[ 84.860321] (sysfs_lock){+.+.+.}, at: [<c0275358>] gpio_value_store+0x24/0xcc
[ 84.860321]
[ 84.860321] but task is already holding lock:
[ 84.860321] (s_active#22){++++.+}, at: [<c016996c>] sysfs_write_file+0xdc/0x184
[ 84.911468]
[ 84.911468] which lock already depends on the new lock.
[ 84.911468]
[ 84.920043]
[ 84.920043] the existing dependency chain (in reverse order) is:
[ 84.920043]
[ 84.927886] -> #1 (s_active#22){++++.+}:
[ 84.927886] [<c008f640>] check_prevs_add+0xdc/0x150
[ 84.927886] [<c008fc18>] validate_chain.clone.24+0x564/0x694
[ 84.927886] [<c0090cdc>] __lock_acquire+0x49c/0x980
[ 84.951660] [<c0091838>] lock_acquire+0x98/0x100
[ 84.951660] [<c016a8e8>] sysfs_deactivate+0xb0/0x100
[ 84.962982] [<c016b1b4>] sysfs_addrm_finish+0x2c/0x6c
[ 84.962982] [<c016b8bc>] sysfs_remove_dir+0x84/0x98
[ 84.962982] [<c02590d8>] kobject_del+0x10/0x78
[ 84.974670] [<c02c29e8>] device_del+0x140/0x170
[ 84.974670] [<c02c2a24>] device_unregister+0xc/0x18
[ 84.985382] [<c0276894>] gpio_unexport+0xbc/0xdc
[ 84.985382] [<c02768c8>] gpio_free+0x14/0xfc
[ 85.001708] [<c0276a28>] unexport_store+0x78/0x8c
[ 85.001708] [<c02c5af8>] class_attr_store+0x18/0x24
[ 85.007293] [<c0169990>] sysfs_write_file+0x100/0x184
[ 85.018981] [<c0109d48>] vfs_write+0xb4/0x148
[ 85.018981] [<c0109fd0>] sys_write+0x40/0x70
[ 85.018981] [<c0013cc0>] ret_fast_syscall+0x0/0x3c
[ 85.035003]
[ 85.035003] -> #0 (sysfs_lock){+.+.+.}:
[ 85.035003] [<c008f54c>] check_prev_add+0x680/0x698
[ 85.035003] [<c008f640>] check_prevs_add+0xdc/0x150
[ 85.052093] [<c008fc18>] validate_chain.clone.24+0x564/0x694
[ 85.052093] [<c0090cdc>] __lock_acquire+0x49c/0x980
[ 85.052093] [<c0091838>] lock_acquire+0x98/0x100
[ 85.069885] [<c047e280>] mutex_lock_nested+0x3c/0x2f4
[ 85.069885] [<c0275358>] gpio_value_store+0x24/0xcc
[ 85.069885] [<c02c18dc>] dev_attr_store+0x18/0x24
[ 85.087158] [<c0169990>] sysfs_write_file+0x100/0x184
[ 85.087158] [<c0109d48>] vfs_write+0xb4/0x148
[ 85.098297] [<c0109fd0>] sys_write+0x40/0x70
[ 85.098297] [<c0013cc0>] ret_fast_syscall+0x0/0x3c
[ 85.109069]
[ 85.109069] other info that might help us debug this:
[ 85.109069]
[ 85.117462] Possible unsafe locking scenario:
[ 85.117462]
[ 85.117462] CPU0 CPU1
[ 85.128417] ---- ----
[ 85.128417] lock(s_active#22);
[ 85.128417] lock(sysfs_lock);
[ 85.128417] lock(s_active#22);
[ 85.142486] lock(sysfs_lock);
[ 85.151794]
[ 85.151794] *** DEADLOCK ***
[ 85.151794]
[ 85.151794] 2 locks held by bash/949:
[ 85.158020] #0: (&buffer->mutex){+.+.+.}, at: [<c01698b8>] sysfs_write_file+0x28/0x184
[ 85.170349] #1: (s_active#22){++++.+}, at: [<c016996c>] sysfs_write_file+0xdc/0x184
[ 85.170349]
[ 85.178588] stack backtrace:
[ 85.178588] [<c001b824>] (unwind_backtrace+0x0/0xf0) from [<c008de64>] (print_circular_bug+0x100/0x114)
[ 85.193023] [<c008de64>] (print_circular_bug+0x100/0x114) from [<c008f54c>] (check_prev_add+0x680/0x698)
[ 85.193023] [<c008f54c>] (check_prev_add+0x680/0x698) from [<c008f640>] (check_prevs_add+0xdc/0x150)
[ 85.212524] [<c008f640>] (check_prevs_add+0xdc/0x150) from [<c008fc18>] (validate_chain.clone.24+0x564/0x694)
[ 85.212524] [<c008fc18>] (validate_chain.clone.24+0x564/0x694) from [<c0090cdc>] (__lock_acquire+0x49c/0x980)
[ 85.233306] [<c0090cdc>] (__lock_acquire+0x49c/0x980) from [<c0091838>] (lock_acquire+0x98/0x100)
[ 85.233306] [<c0091838>] (lock_acquire+0x98/0x100) from [<c047e280>] (mutex_lock_nested+0x3c/0x2f4)
[ 85.242614] [<c047e280>] (mutex_lock_nested+0x3c/0x2f4) from [<c0275358>] (gpio_value_store+0x24/0xcc)
[ 85.261840] [<c0275358>] (gpio_value_store+0x24/0xcc) from [<c02c18dc>] (dev_attr_store+0x18/0x24)
[ 85.261840] [<c02c18dc>] (dev_attr_store+0x18/0x24) from [<c0169990>] (sysfs_write_file+0x100/0x184)
[ 85.271240] [<c0169990>] (sysfs_write_file+0x100/0x184) from [<c0109d48>] (vfs_write+0xb4/0x148)
[ 85.290008] [<c0109d48>] (vfs_write+0xb4/0x148) from [<c0109fd0>] (sys_write+0x40/0x70)
[ 85.298400] [<c0109fd0>] (sys_write+0x40/0x70) from [<c0013cc0>] (ret_fast_syscall+0x0/0x3c)
-bash: echo: write error: Operation not permitted
the way to trigger is:
root at legolas:~# cd /sys/class/gpio/
root at legolas:/sys/class/gpio# echo 2 > export
root at legolas:/sys/class/gpio# echo 2 > unexport
root at legolas:/sys/class/gpio# echo 2 > export
root at legolas:/sys/class/gpio# cd gpio2/
root at legolas:/sys/class/gpio/gpio2# echo 1 > value
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120208/b305de2d/attachment.sig>
More information about the linux-arm-kernel
mailing list