2012-02-08 12:41:54

by Felipe Balbi

[permalink] [raw]
Subject: Possible circular locking dependency (3.3-rc2)

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


Attachments:
(No filename) (5.10 kB)
signature.asc (836.00 B)
Digital signature
Download all attachments

2012-02-12 13:32:08

by Maciej Rutecki

[permalink] [raw]
Subject: Re: Possible circular locking dependency (3.3-rc2)

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

2012-02-13 14:53:31

by Ming Lei

[permalink] [raw]
Subject: Re: Possible circular locking dependency (3.3-rc2)

Hi,

On Wed, Feb 8, 2012 at 8:41 PM, Felipe Balbi <[email protected]> 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

2012-02-15 18:54:58

by Linus Walleij

[permalink] [raw]
Subject: Re: Possible circular locking dependency (3.3-rc2)

On Mon, Feb 13, 2012 at 3:53 PM, Ming Lei <[email protected]> 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 <[email protected]>

Thanks,
Linus Walleij

2012-02-15 20:07:38

by Grant Likely

[permalink] [raw]
Subject: Re: Possible circular locking dependency (3.3-rc2)

On Wed, Feb 15, 2012 at 07:54:56PM +0100, Linus Walleij wrote:
> On Mon, Feb 13, 2012 at 3:53 PM, Ming Lei <[email protected]> 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 <[email protected]>

Ming, can I have a proper Signed-off-by: line from you so I can apply this
patch?

Thanks,
g.

2012-02-15 20:09:17

by Grant Likely

[permalink] [raw]
Subject: Re: Possible circular locking dependency (3.3-rc2)

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 <[email protected]> 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

2012-02-16 00:05:44

by Ming Lei

[permalink] [raw]
Subject: Re: Possible circular locking dependency (3.3-rc2)

On Thu, Feb 16, 2012 at 4:07 AM, Grant Likely <[email protected]> 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 <[email protected]> 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 <[email protected]>
>
> Ming, can I have a proper Signed-off-by: line from you so I can apply this
> patch?

Sure, :-)

thanks
--
Ming Lei

2012-02-20 08:08:34

by Thomas Weber

[permalink] [raw]
Subject: Re: Possible circular locking dependency (3.3-rc2)

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)

2012-02-20 09:09:15

by NeilBrown

[permalink] [raw]
Subject: Re: Possible circular locking dependency (3.3-rc2)

On Mon, 20 Feb 2012 09:07:42 +0100 Thomas Weber
<[email protected]> 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)


Attachments:
signature.asc (828.00 B)