* Possible circular locking dependency (3.3-rc2) @ 2012-02-08 12:41 Felipe Balbi 2012-02-12 13:31 ` Maciej Rutecki 2012-02-13 14:53 ` Ming Lei 0 siblings, 2 replies; 9+ messages in thread From: Felipe Balbi @ 2012-02-08 12:41 UTC (permalink / raw) To: linux-arm-kernel 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> ^ permalink raw reply [flat|nested] 9+ messages in thread
* Possible circular locking dependency (3.3-rc2) 2012-02-08 12:41 Possible circular locking dependency (3.3-rc2) Felipe Balbi @ 2012-02-12 13:31 ` Maciej Rutecki 2012-02-13 14:53 ` Ming Lei 1 sibling, 0 replies; 9+ messages in thread From: Maciej Rutecki @ 2012-02-12 13:31 UTC (permalink / raw) To: linux-arm-kernel On ?roda, 8 lutego 2012 o 13:41:48 Felipe Balbi wrote: > 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 I created a Bugzilla entry at https://bugzilla.kernel.org/show_bug.cgi?id=42761 for your bug/regression report, please add your address to the CC list in there, thanks! -- Maciej Rutecki http://www.mrutecki.pl ^ permalink raw reply [flat|nested] 9+ messages in thread
* Possible circular locking dependency (3.3-rc2) 2012-02-08 12:41 Possible circular locking dependency (3.3-rc2) Felipe Balbi 2012-02-12 13:31 ` Maciej Rutecki @ 2012-02-13 14:53 ` Ming Lei 2012-02-15 18:54 ` Linus Walleij 2012-02-15 20:09 ` Grant Likely 1 sibling, 2 replies; 9+ messages in thread From: Ming Lei @ 2012-02-13 14:53 UTC (permalink / raw) To: linux-arm-kernel Hi, On Wed, Feb 8, 2012 at 8:41 PM, Felipe Balbi <balbi@ti.com> wrote: > 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 Looks 'sysfs_lock' needn't to be held for unregister, so the patch below may fix the problem. diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index 17fdf4b..d773540 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -873,6 +873,7 @@ void gpio_unexport(unsigned gpio) { struct gpio_desc *desc; int status = 0; + struct device *dev = NULL; if (!gpio_is_valid(gpio)) { status = -EINVAL; @@ -884,19 +885,20 @@ void gpio_unexport(unsigned gpio) desc = &gpio_desc[gpio]; if (test_bit(FLAG_EXPORT, &desc->flags)) { - struct device *dev = NULL; dev = class_find_device(&gpio_class, NULL, desc, match_export); if (dev) { gpio_setup_irq(desc, dev, 0); clear_bit(FLAG_EXPORT, &desc->flags); - put_device(dev); - device_unregister(dev); } else status = -ENODEV; } mutex_unlock(&sysfs_lock); + if (dev) { + device_unregister(dev); + put_device(dev); + } done: if (status) pr_debug("%s: gpio%d status %d\n", __func__, gpio, status); thanks, -- Ming Lei ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Possible circular locking dependency (3.3-rc2) 2012-02-13 14:53 ` Ming Lei @ 2012-02-15 18:54 ` Linus Walleij 2012-02-15 20:07 ` Grant Likely 2012-02-15 20:09 ` Grant Likely 1 sibling, 1 reply; 9+ messages in thread From: Linus Walleij @ 2012-02-15 18:54 UTC (permalink / raw) To: linux-arm-kernel On Mon, Feb 13, 2012 at 3:53 PM, Ming Lei <tom.leiming@gmail.com> wrote: > Looks 'sysfs_lock' needn't to be held for unregister, so the patch below may > fix the problem. Looks correct to me! Acked-by: Linus Walleij <linus.walleij@linaro.org> Thanks, Linus Walleij ^ permalink raw reply [flat|nested] 9+ messages in thread
* Possible circular locking dependency (3.3-rc2) 2012-02-15 18:54 ` Linus Walleij @ 2012-02-15 20:07 ` Grant Likely 2012-02-16 0:05 ` Ming Lei 0 siblings, 1 reply; 9+ messages in thread From: Grant Likely @ 2012-02-15 20:07 UTC (permalink / raw) To: linux-arm-kernel On Wed, Feb 15, 2012 at 07:54:56PM +0100, Linus Walleij wrote: > On Mon, Feb 13, 2012 at 3:53 PM, Ming Lei <tom.leiming@gmail.com> wrote: > > > Looks 'sysfs_lock' needn't to be held for unregister, so the patch below may > > fix the problem. > > Looks correct to me! > Acked-by: Linus Walleij <linus.walleij@linaro.org> Ming, can I have a proper Signed-off-by: line from you so I can apply this patch? Thanks, g. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Possible circular locking dependency (3.3-rc2) 2012-02-15 20:07 ` Grant Likely @ 2012-02-16 0:05 ` Ming Lei 0 siblings, 0 replies; 9+ messages in thread From: Ming Lei @ 2012-02-16 0:05 UTC (permalink / raw) To: linux-arm-kernel On Thu, Feb 16, 2012 at 4:07 AM, Grant Likely <grant.likely@secretlab.ca> wrote: > On Wed, Feb 15, 2012 at 07:54:56PM +0100, Linus Walleij wrote: >> On Mon, Feb 13, 2012 at 3:53 PM, Ming Lei <tom.leiming@gmail.com> wrote: >> >> > Looks 'sysfs_lock' needn't to be held for unregister, so the patch below may >> > fix the problem. >> >> Looks correct to me! >> Acked-by: Linus Walleij <linus.walleij@linaro.org> > > Ming, can I have a proper Signed-off-by: line from you so I can apply this > patch? Sure, :-) thanks -- Ming Lei ^ permalink raw reply [flat|nested] 9+ messages in thread
* Possible circular locking dependency (3.3-rc2) 2012-02-13 14:53 ` Ming Lei 2012-02-15 18:54 ` Linus Walleij @ 2012-02-15 20:09 ` Grant Likely 2012-02-20 8:07 ` Thomas Weber 1 sibling, 1 reply; 9+ messages in thread From: Grant Likely @ 2012-02-15 20:09 UTC (permalink / raw) To: linux-arm-kernel Felipe, can you confirm whether or not Ming's patch below solves your problem? g. On Mon, Feb 13, 2012 at 10:53:20PM +0800, Ming Lei wrote: > Hi, > > On Wed, Feb 8, 2012 at 8:41 PM, Felipe Balbi <balbi@ti.com> wrote: > > 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 > > Looks 'sysfs_lock' needn't to be held for unregister, so the patch below may > fix the problem. > > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c > index 17fdf4b..d773540 100644 > --- a/drivers/gpio/gpiolib.c > +++ b/drivers/gpio/gpiolib.c > @@ -873,6 +873,7 @@ void gpio_unexport(unsigned gpio) > { > struct gpio_desc *desc; > int status = 0; > + struct device *dev = NULL; > > if (!gpio_is_valid(gpio)) { > status = -EINVAL; > @@ -884,19 +885,20 @@ void gpio_unexport(unsigned gpio) > desc = &gpio_desc[gpio]; > > if (test_bit(FLAG_EXPORT, &desc->flags)) { > - struct device *dev = NULL; > > dev = class_find_device(&gpio_class, NULL, desc, match_export); > if (dev) { > gpio_setup_irq(desc, dev, 0); > clear_bit(FLAG_EXPORT, &desc->flags); > - put_device(dev); > - device_unregister(dev); > } else > status = -ENODEV; > } > > mutex_unlock(&sysfs_lock); > + if (dev) { > + device_unregister(dev); > + put_device(dev); > + } > done: > if (status) > pr_debug("%s: gpio%d status %d\n", __func__, gpio, status); > > > thanks, > -- > Ming Lei ^ permalink raw reply [flat|nested] 9+ messages in thread
* Possible circular locking dependency (3.3-rc2) 2012-02-15 20:09 ` Grant Likely @ 2012-02-20 8:07 ` Thomas Weber 2012-02-20 9:08 ` NeilBrown 0 siblings, 1 reply; 9+ messages in thread From: Thomas Weber @ 2012-02-20 8:07 UTC (permalink / raw) To: linux-arm-kernel Hello, I applied the patch from Ming, but got also an error. I am ccing Neil, because I also applied some patches from him. Regards, Thomas > [ 6.229370] ====================================================== > [ 6.235870] [ INFO: possible circular locking dependency detected ] > [ 6.242431] 3.3.0-rc4-00020-ga02b31a #10 Not tainted > [ 6.247650] ------------------------------------------------------- > [ 6.254241] udevadm/596 is trying to acquire lock: > [ 6.259277] (&dev->mutex#2){+.+.+.}, at: [<c0308af0>] w1_bq27000_read+0x1c/0x48 > [ 6.267120] > [ 6.267120] but task is already holding lock: > [ 6.273254] (s_active#11){++++.+}, at: [<c01463d4>] sysfs_write_file+0xdc/0x180 > [ 6.281097] > [ 6.281127] which lock already depends on the new lock. > [ 6.281127] > [ 6.289703] > [ 6.289703] the existing dependency chain (in reverse order) is: > [ 6.297576] > [ 6.297576] -> #1 (s_active#11){++++.+}: > [ 6.303283] [<c007b3c8>] lock_acquire+0xa0/0x128 > [ 6.308807] [<c0147b50>] sysfs_addrm_finish+0xf4/0x148 > [ 6.314880] [<c0146184>] sysfs_hash_and_remove+0x4c/0x88 > [ 6.321136] [<c0146cec>] sysfs_remove_file+0x30/0x38 > [ 6.326995] [<c0275bec>] device_del+0xf0/0x17c > [ 6.332336] [<c0275c84>] device_unregister+0xc/0x18 > [ 6.338104] [<c0306b28>] w1_slave_detach+0xac/0xcc > [ 6.343811] [<c0306e5c>] w1_reconnect_slaves+0xc0/0x10c > [ 6.349945] [<c0307924>] w1_register_family+0x90/0xa0 > [ 6.355926] [<c0008760>] do_one_initcall+0x34/0x174 > [ 6.361694] [<c054980c>] kernel_init+0x94/0x11c > [ 6.367126] [<c00148b0>] kernel_thread_exit+0x0/0x8 > [ 6.372924] > [ 6.372924] -> #0 (&dev->mutex#2){+.+.+.}: > [ 6.378845] [<c007a980>] __lock_acquire+0x1678/0x1ad4 > [ 6.384826] [<c007b3c8>] lock_acquire+0xa0/0x128 > [ 6.390319] [<c03c7b24>] mutex_lock_nested+0x48/0x2bc > [ 6.396301] [<c0308af0>] w1_bq27000_read+0x1c/0x48 > [ 6.401977] [<c03098d4>] bq27000_read_platform+0x2c/0x124 > [ 6.408325] [<c030a004>] bq27x00_battery_get_property+0x1cc/0x3cc > [ 6.415374] [<c0309154>] power_supply_show_property+0x4c/0x224 > [ 6.422180] [<c0309468>] power_supply_uevent+0xe4/0x224 > [ 6.428314] [<c0276b60>] dev_uevent+0xb4/0x170 > [ 6.433654] [<c01f4b84>] kobject_uevent_env+0x1d8/0x478 > [ 6.439819] [<c027603c>] store_uevent+0x50/0x54 > [ 6.445220] [<c0274f58>] dev_attr_store+0x18/0x24 > [ 6.450805] [<c01463f8>] sysfs_write_file+0x100/0x180 > [ 6.456787] [<c00e96a0>] vfs_write+0xa8/0x138 > [ 6.462036] [<c00e9910>] sys_write+0x40/0x6c > [ 6.467163] [<c00138e0>] ret_fast_syscall+0x0/0x3c > [ 6.472869] > [ 6.472869] other info that might help us debug this: > [ 6.472900] > [ 6.481292] Possible unsafe locking scenario: > [ 6.481292] > [ 6.487518] CPU0 CPU1 > [ 6.492248] ---- ---- > [ 6.497009] lock(s_active#11); > [ 6.500427] lock(&dev->mutex#2); > [ 6.506683] lock(s_active#11); > [ 6.512756] lock(&dev->mutex#2); > [ 6.516357] > [ 6.516357] *** DEADLOCK *** > [ 6.516357] > [ 6.522583] 2 locks held by udevadm/596: > [ 6.526702] #0: (&buffer->mutex){+.+.+.}, at: [<c0146320>] sysfs_write_file+0x28/0x180 > [ 6.535278] #1: (s_active#11){++++.+}, at: [<c01463d4>] sysfs_write_file+0xdc/0x180 > [ 6.543579] > [ 6.543579] > [ 6.543579] stack backtrace: > [ 6.548217] [<c0019e9c>] (unwind_backtrace+0x0/0xf8) from [<c03c3544>] (print_circular_bug+0x2c8/0x2d4) > [ 6.558105] [<c03c3544>] (print_circular_bug+0x2c8/0x2d4) from [<c007a980>] (__lock_acquire+0x1678/0x1ad4) > [ 6.568267] [<c007a980>] (__lock_acquire+0x1678/0x1ad4) from [<c007b3c8>] (lock_acquire+0xa0/0x128) > [ 6.577789] [<c007b3c8>] (lock_acquire+0xa0/0x128) from [<c03c7b24>] (mutex_lock_nested+0x48/0x2bc) > [ 6.587310] [<c03c7b24>] (mutex_lock_nested+0x48/0x2bc) from [<c0308af0>] (w1_bq27000_read+0x1c/0x48) > [ 6.597015] [<c0308af0>] (w1_bq27000_read+0x1c/0x48) from [<c03098d4>] (bq27000_read_platform+0x2c/0x124) > [ 6.607086] [<c03098d4>] (bq27000_read_platform+0x2c/0x124) from [<c030a004>] (bq27x00_battery_get_property+0x1cc/0x3cc) > [ 6.618499] [<c030a004>] (bq27x00_battery_get_property+0x1cc/0x3cc) from [<c0309154>] (power_supply_show_property+0x4c/0x224) > [ 6.630401] [<c0309154>] (power_supply_show_property+0x4c/0x224) from [<c0309468>] (power_supply_uevent+0xe4/0x224) > [ 6.641357] [<c0309468>] (power_supply_uevent+0xe4/0x224) from [<c0276b60>] (dev_uevent+0xb4/0x170) > [ 6.650909] [<c0276b60>] (dev_uevent+0xb4/0x170) from [<c01f4b84>] (kobject_uevent_env+0x1d8/0x478) > [ 6.660430] [<c01f4b84>] (kobject_uevent_env+0x1d8/0x478) from [<c027603c>] (store_uevent+0x50/0x54) > [ 6.670013] [<c027603c>] (store_uevent+0x50/0x54) from [<c0274f58>] (dev_attr_store+0x18/0x24) > [ 6.679107] [<c0274f58>] (dev_attr_store+0x18/0x24) from [<c01463f8>] (sysfs_write_file+0x100/0x180) > [ 6.688720] [<c01463f8>] (sysfs_write_file+0x100/0x180) from [<c00e96a0>] (vfs_write+0xa8/0x138) > [ 6.697967] [<c00e96a0>] (vfs_write+0xa8/0x138) from [<c00e9910>] (sys_write+0x40/0x6c) > [ 6.706390] [<c00e9910>] (sys_write+0x40/0x6c) from [<c00138e0>] (ret_fast_syscall+0x0/0x3c) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Possible circular locking dependency (3.3-rc2) 2012-02-20 8:07 ` Thomas Weber @ 2012-02-20 9:08 ` NeilBrown 0 siblings, 0 replies; 9+ messages in thread From: NeilBrown @ 2012-02-20 9:08 UTC (permalink / raw) To: linux-arm-kernel On Mon, 20 Feb 2012 09:07:42 +0100 Thomas Weber <thomas.weber.linux@googlemail.com> wrote: > Hello, > > I applied the patch from Ming, but got also an error. > I am ccing Neil, because I also applied some patches from him. That looks like it is the third of the three patches I sent. I needed some locking and there was a mutex available that seemed to be available so I used it. Apparently it causes problems. I don't think I ever saw that myself ... I wonder why. There is already a dependency between the mutex I used and s_active in sysfs. I guess that means I'll have to create a new lock just for the purpose of keeping two threads from using the w1 bus at the same time... Apart from this - which is just a warning, though maybe it could become a real deadlock - is the bq27000 now working for you? NeilBrown > > Regards, > Thomas > > > [ 6.229370] ====================================================== > > [ 6.235870] [ INFO: possible circular locking dependency detected ] > > [ 6.242431] 3.3.0-rc4-00020-ga02b31a #10 Not tainted > > [ 6.247650] ------------------------------------------------------- > > [ 6.254241] udevadm/596 is trying to acquire lock: > > [ 6.259277] (&dev->mutex#2){+.+.+.}, at: [<c0308af0>] w1_bq27000_read+0x1c/0x48 > > [ 6.267120] > > [ 6.267120] but task is already holding lock: > > [ 6.273254] (s_active#11){++++.+}, at: [<c01463d4>] sysfs_write_file+0xdc/0x180 > > [ 6.281097] > > [ 6.281127] which lock already depends on the new lock. > > [ 6.281127] > > [ 6.289703] > > [ 6.289703] the existing dependency chain (in reverse order) is: > > [ 6.297576] > > [ 6.297576] -> #1 (s_active#11){++++.+}: > > [ 6.303283] [<c007b3c8>] lock_acquire+0xa0/0x128 > > [ 6.308807] [<c0147b50>] sysfs_addrm_finish+0xf4/0x148 > > [ 6.314880] [<c0146184>] sysfs_hash_and_remove+0x4c/0x88 > > [ 6.321136] [<c0146cec>] sysfs_remove_file+0x30/0x38 > > [ 6.326995] [<c0275bec>] device_del+0xf0/0x17c > > [ 6.332336] [<c0275c84>] device_unregister+0xc/0x18 > > [ 6.338104] [<c0306b28>] w1_slave_detach+0xac/0xcc > > [ 6.343811] [<c0306e5c>] w1_reconnect_slaves+0xc0/0x10c > > [ 6.349945] [<c0307924>] w1_register_family+0x90/0xa0 > > [ 6.355926] [<c0008760>] do_one_initcall+0x34/0x174 > > [ 6.361694] [<c054980c>] kernel_init+0x94/0x11c > > [ 6.367126] [<c00148b0>] kernel_thread_exit+0x0/0x8 > > [ 6.372924] > > [ 6.372924] -> #0 (&dev->mutex#2){+.+.+.}: > > [ 6.378845] [<c007a980>] __lock_acquire+0x1678/0x1ad4 > > [ 6.384826] [<c007b3c8>] lock_acquire+0xa0/0x128 > > [ 6.390319] [<c03c7b24>] mutex_lock_nested+0x48/0x2bc > > [ 6.396301] [<c0308af0>] w1_bq27000_read+0x1c/0x48 > > [ 6.401977] [<c03098d4>] bq27000_read_platform+0x2c/0x124 > > [ 6.408325] [<c030a004>] bq27x00_battery_get_property+0x1cc/0x3cc > > [ 6.415374] [<c0309154>] power_supply_show_property+0x4c/0x224 > > [ 6.422180] [<c0309468>] power_supply_uevent+0xe4/0x224 > > [ 6.428314] [<c0276b60>] dev_uevent+0xb4/0x170 > > [ 6.433654] [<c01f4b84>] kobject_uevent_env+0x1d8/0x478 > > [ 6.439819] [<c027603c>] store_uevent+0x50/0x54 > > [ 6.445220] [<c0274f58>] dev_attr_store+0x18/0x24 > > [ 6.450805] [<c01463f8>] sysfs_write_file+0x100/0x180 > > [ 6.456787] [<c00e96a0>] vfs_write+0xa8/0x138 > > [ 6.462036] [<c00e9910>] sys_write+0x40/0x6c > > [ 6.467163] [<c00138e0>] ret_fast_syscall+0x0/0x3c > > [ 6.472869] > > [ 6.472869] other info that might help us debug this: > > [ 6.472900] > > [ 6.481292] Possible unsafe locking scenario: > > [ 6.481292] > > [ 6.487518] CPU0 CPU1 > > [ 6.492248] ---- ---- > > [ 6.497009] lock(s_active#11); > > [ 6.500427] lock(&dev->mutex#2); > > [ 6.506683] lock(s_active#11); > > [ 6.512756] lock(&dev->mutex#2); > > [ 6.516357] > > [ 6.516357] *** DEADLOCK *** > > [ 6.516357] > > [ 6.522583] 2 locks held by udevadm/596: > > [ 6.526702] #0: (&buffer->mutex){+.+.+.}, at: [<c0146320>] sysfs_write_file+0x28/0x180 > > [ 6.535278] #1: (s_active#11){++++.+}, at: [<c01463d4>] sysfs_write_file+0xdc/0x180 > > [ 6.543579] > > [ 6.543579] > > [ 6.543579] stack backtrace: > > [ 6.548217] [<c0019e9c>] (unwind_backtrace+0x0/0xf8) from [<c03c3544>] (print_circular_bug+0x2c8/0x2d4) > > [ 6.558105] [<c03c3544>] (print_circular_bug+0x2c8/0x2d4) from [<c007a980>] (__lock_acquire+0x1678/0x1ad4) > > [ 6.568267] [<c007a980>] (__lock_acquire+0x1678/0x1ad4) from [<c007b3c8>] (lock_acquire+0xa0/0x128) > > [ 6.577789] [<c007b3c8>] (lock_acquire+0xa0/0x128) from [<c03c7b24>] (mutex_lock_nested+0x48/0x2bc) > > [ 6.587310] [<c03c7b24>] (mutex_lock_nested+0x48/0x2bc) from [<c0308af0>] (w1_bq27000_read+0x1c/0x48) > > [ 6.597015] [<c0308af0>] (w1_bq27000_read+0x1c/0x48) from [<c03098d4>] (bq27000_read_platform+0x2c/0x124) > > [ 6.607086] [<c03098d4>] (bq27000_read_platform+0x2c/0x124) from [<c030a004>] (bq27x00_battery_get_property+0x1cc/0x3cc) > > [ 6.618499] [<c030a004>] (bq27x00_battery_get_property+0x1cc/0x3cc) from [<c0309154>] (power_supply_show_property+0x4c/0x224) > > [ 6.630401] [<c0309154>] (power_supply_show_property+0x4c/0x224) from [<c0309468>] (power_supply_uevent+0xe4/0x224) > > [ 6.641357] [<c0309468>] (power_supply_uevent+0xe4/0x224) from [<c0276b60>] (dev_uevent+0xb4/0x170) > > [ 6.650909] [<c0276b60>] (dev_uevent+0xb4/0x170) from [<c01f4b84>] (kobject_uevent_env+0x1d8/0x478) > > [ 6.660430] [<c01f4b84>] (kobject_uevent_env+0x1d8/0x478) from [<c027603c>] (store_uevent+0x50/0x54) > > [ 6.670013] [<c027603c>] (store_uevent+0x50/0x54) from [<c0274f58>] (dev_attr_store+0x18/0x24) > > [ 6.679107] [<c0274f58>] (dev_attr_store+0x18/0x24) from [<c01463f8>] (sysfs_write_file+0x100/0x180) > > [ 6.688720] [<c01463f8>] (sysfs_write_file+0x100/0x180) from [<c00e96a0>] (vfs_write+0xa8/0x138) > > [ 6.697967] [<c00e96a0>] (vfs_write+0xa8/0x138) from [<c00e9910>] (sys_write+0x40/0x6c) > > [ 6.706390] [<c00e9910>] (sys_write+0x40/0x6c) from [<c00138e0>] (ret_fast_syscall+0x0/0x3c) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 828 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120220/16eb3302/attachment.sig> ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-02-20 9:08 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-02-08 12:41 Possible circular locking dependency (3.3-rc2) Felipe Balbi 2012-02-12 13:31 ` Maciej Rutecki 2012-02-13 14:53 ` Ming Lei 2012-02-15 18:54 ` Linus Walleij 2012-02-15 20:07 ` Grant Likely 2012-02-16 0:05 ` Ming Lei 2012-02-15 20:09 ` Grant Likely 2012-02-20 8:07 ` Thomas Weber 2012-02-20 9:08 ` NeilBrown
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).