* 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-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: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-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).