* 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: Grant Likely, Linus Walleij Cc: Linux OMAP Mailing List, Linux Kernel Mailing List, Linux ARM Kernel Mailing List [-- Attachment #1: Type: text/plain, Size: 5320 bytes --] 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@legolas:~# cd /sys/class/gpio/ root@legolas:/sys/class/gpio# echo 2 > export root@legolas:/sys/class/gpio# echo 2 > unexport root@legolas:/sys/class/gpio# echo 2 > export root@legolas:/sys/class/gpio# cd gpio2/ root@legolas:/sys/class/gpio/gpio2# echo 1 > value -- balbi [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: 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: balbi Cc: Grant Likely, Linus Walleij, Linux OMAP Mailing List, Linux Kernel Mailing List, Linux ARM Kernel Mailing List 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@legolas:~# cd /sys/class/gpio/ > root@legolas:/sys/class/gpio# echo 2 > export > root@legolas:/sys/class/gpio# echo 2 > unexport > root@legolas:/sys/class/gpio# echo 2 > export > root@legolas:/sys/class/gpio# cd gpio2/ > root@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
* Re: 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: balbi Cc: Grant Likely, Linus Walleij, Linux OMAP Mailing List, Linux Kernel Mailing List, Linux ARM Kernel Mailing List 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@legolas:~# cd /sys/class/gpio/ > root@legolas:/sys/class/gpio# echo 2 > export > root@legolas:/sys/class/gpio# echo 2 > unexport > root@legolas:/sys/class/gpio# echo 2 > export > root@legolas:/sys/class/gpio# cd gpio2/ > root@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
* Re: 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: Ming Lei Cc: balbi, Grant Likely, Linus Walleij, Linux OMAP Mailing List, Linux Kernel Mailing List, Linux ARM Kernel Mailing List 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
* Re: 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: Linus Walleij Cc: Ming Lei, balbi, Linus Walleij, Linux OMAP Mailing List, Linux Kernel Mailing List, Linux ARM Kernel Mailing List 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
* Re: 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: Grant Likely Cc: Linus Walleij, balbi, Linus Walleij, Linux OMAP Mailing List, Linux Kernel Mailing List, Linux ARM Kernel Mailing List 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
* Re: 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: Ming Lei Cc: balbi, Linus Walleij, Linux OMAP Mailing List, Linux Kernel Mailing List, Linux ARM Kernel Mailing List 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@legolas:~# cd /sys/class/gpio/ > > root@legolas:/sys/class/gpio# echo 2 > export > > root@legolas:/sys/class/gpio# echo 2 > unexport > > root@legolas:/sys/class/gpio# echo 2 > export > > root@legolas:/sys/class/gpio# cd gpio2/ > > root@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
* Re: 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: Grant Likely Cc: Ming Lei, balbi, Linus Walleij, Linux OMAP Mailing List, Linux Kernel Mailing List, Linux ARM Kernel Mailing List, NeilBrown 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
* Re: 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: Thomas Weber Cc: Grant Likely, Ming Lei, balbi, Linus Walleij, Linux OMAP Mailing List, Linux Kernel Mailing List, Linux ARM Kernel Mailing List [-- Attachment #1: Type: text/plain, Size: 6531 bytes --] 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) [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 828 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-02-20 9:09 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).