* Possible circular locking dependency (3.3-rc2)
@ 2012-02-13 14:53 ` Ming Lei
0 siblings, 0 replies; 19+ messages in thread
From: Ming Lei @ 2012-02-13 14:53 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Wed, Feb 8, 2012 at 8:41 PM, Felipe Balbi <balbi@ti.com> wrote:
> Hi guys,
>
> I have just triggered the folllowing:
>
> [ ? 84.860321] ======================================================
> [ ? 84.860321] [ INFO: possible circular locking dependency detected ]
> [ ? 84.860321] 3.3.0-rc2-00026-ge4e8a39 #474 Not tainted
> [ ? 84.860321] -------------------------------------------------------
> [ ? 84.860321] bash/949 is trying to acquire lock:
> [ ? 84.860321] ?(sysfs_lock){+.+.+.}, at: [<c0275358>] gpio_value_store+0x24/0xcc
> [ ? 84.860321]
> [ ? 84.860321] but task is already holding lock:
> [ ? 84.860321] ?(s_active#22){++++.+}, at: [<c016996c>] sysfs_write_file+0xdc/0x184
> [ ? 84.911468]
> [ ? 84.911468] which lock already depends on the new lock.
> [ ? 84.911468]
> [ ? 84.920043]
> [ ? 84.920043] the existing dependency chain (in reverse order) is:
> [ ? 84.920043]
> [ ? 84.927886] -> #1 (s_active#22){++++.+}:
> [ ? 84.927886] ? ? ? ?[<c008f640>] check_prevs_add+0xdc/0x150
> [ ? 84.927886] ? ? ? ?[<c008fc18>] validate_chain.clone.24+0x564/0x694
> [ ? 84.927886] ? ? ? ?[<c0090cdc>] __lock_acquire+0x49c/0x980
> [ ? 84.951660] ? ? ? ?[<c0091838>] lock_acquire+0x98/0x100
> [ ? 84.951660] ? ? ? ?[<c016a8e8>] sysfs_deactivate+0xb0/0x100
> [ ? 84.962982] ? ? ? ?[<c016b1b4>] sysfs_addrm_finish+0x2c/0x6c
> [ ? 84.962982] ? ? ? ?[<c016b8bc>] sysfs_remove_dir+0x84/0x98
> [ ? 84.962982] ? ? ? ?[<c02590d8>] kobject_del+0x10/0x78
> [ ? 84.974670] ? ? ? ?[<c02c29e8>] device_del+0x140/0x170
> [ ? 84.974670] ? ? ? ?[<c02c2a24>] device_unregister+0xc/0x18
> [ ? 84.985382] ? ? ? ?[<c0276894>] gpio_unexport+0xbc/0xdc
> [ ? 84.985382] ? ? ? ?[<c02768c8>] gpio_free+0x14/0xfc
> [ ? 85.001708] ? ? ? ?[<c0276a28>] unexport_store+0x78/0x8c
> [ ? 85.001708] ? ? ? ?[<c02c5af8>] class_attr_store+0x18/0x24
> [ ? 85.007293] ? ? ? ?[<c0169990>] sysfs_write_file+0x100/0x184
> [ ? 85.018981] ? ? ? ?[<c0109d48>] vfs_write+0xb4/0x148
> [ ? 85.018981] ? ? ? ?[<c0109fd0>] sys_write+0x40/0x70
> [ ? 85.018981] ? ? ? ?[<c0013cc0>] ret_fast_syscall+0x0/0x3c
> [ ? 85.035003]
> [ ? 85.035003] -> #0 (sysfs_lock){+.+.+.}:
> [ ? 85.035003] ? ? ? ?[<c008f54c>] check_prev_add+0x680/0x698
> [ ? 85.035003] ? ? ? ?[<c008f640>] check_prevs_add+0xdc/0x150
> [ ? 85.052093] ? ? ? ?[<c008fc18>] validate_chain.clone.24+0x564/0x694
> [ ? 85.052093] ? ? ? ?[<c0090cdc>] __lock_acquire+0x49c/0x980
> [ ? 85.052093] ? ? ? ?[<c0091838>] lock_acquire+0x98/0x100
> [ ? 85.069885] ? ? ? ?[<c047e280>] mutex_lock_nested+0x3c/0x2f4
> [ ? 85.069885] ? ? ? ?[<c0275358>] gpio_value_store+0x24/0xcc
> [ ? 85.069885] ? ? ? ?[<c02c18dc>] dev_attr_store+0x18/0x24
> [ ? 85.087158] ? ? ? ?[<c0169990>] sysfs_write_file+0x100/0x184
> [ ? 85.087158] ? ? ? ?[<c0109d48>] vfs_write+0xb4/0x148
> [ ? 85.098297] ? ? ? ?[<c0109fd0>] sys_write+0x40/0x70
> [ ? 85.098297] ? ? ? ?[<c0013cc0>] ret_fast_syscall+0x0/0x3c
> [ ? 85.109069]
> [ ? 85.109069] other info that might help us debug this:
> [ ? 85.109069]
> [ ? 85.117462] ?Possible unsafe locking scenario:
> [ ? 85.117462]
> [ ? 85.117462] ? ? ? ?CPU0 ? ? ? ? ? ? ? ? ? ?CPU1
> [ ? 85.128417] ? ? ? ?---- ? ? ? ? ? ? ? ? ? ?----
> [ ? 85.128417] ? lock(s_active#22);
> [ ? 85.128417] ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?lock(sysfs_lock);
> [ ? 85.128417] ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?lock(s_active#22);
> [ ? 85.142486] ? lock(sysfs_lock);
> [ ? 85.151794]
> [ ? 85.151794] ?*** DEADLOCK ***
> [ ? 85.151794]
> [ ? 85.151794] 2 locks held by bash/949:
> [ ? 85.158020] ?#0: ?(&buffer->mutex){+.+.+.}, at: [<c01698b8>] sysfs_write_file+0x28/0x184
> [ ? 85.170349] ?#1: ?(s_active#22){++++.+}, at: [<c016996c>] sysfs_write_file+0xdc/0x184
> [ ? 85.170349]
> [ ? 85.178588] stack backtrace:
> [ ? 85.178588] [<c001b824>] (unwind_backtrace+0x0/0xf0) from [<c008de64>] (print_circular_bug+0x100/0x114)
> [ ? 85.193023] [<c008de64>] (print_circular_bug+0x100/0x114) from [<c008f54c>] (check_prev_add+0x680/0x698)
> [ ? 85.193023] [<c008f54c>] (check_prev_add+0x680/0x698) from [<c008f640>] (check_prevs_add+0xdc/0x150)
> [ ? 85.212524] [<c008f640>] (check_prevs_add+0xdc/0x150) from [<c008fc18>] (validate_chain.clone.24+0x564/0x694)
> [ ? 85.212524] [<c008fc18>] (validate_chain.clone.24+0x564/0x694) from [<c0090cdc>] (__lock_acquire+0x49c/0x980)
> [ ? 85.233306] [<c0090cdc>] (__lock_acquire+0x49c/0x980) from [<c0091838>] (lock_acquire+0x98/0x100)
> [ ? 85.233306] [<c0091838>] (lock_acquire+0x98/0x100) from [<c047e280>] (mutex_lock_nested+0x3c/0x2f4)
> [ ? 85.242614] [<c047e280>] (mutex_lock_nested+0x3c/0x2f4) from [<c0275358>] (gpio_value_store+0x24/0xcc)
> [ ? 85.261840] [<c0275358>] (gpio_value_store+0x24/0xcc) from [<c02c18dc>] (dev_attr_store+0x18/0x24)
> [ ? 85.261840] [<c02c18dc>] (dev_attr_store+0x18/0x24) from [<c0169990>] (sysfs_write_file+0x100/0x184)
> [ ? 85.271240] [<c0169990>] (sysfs_write_file+0x100/0x184) from [<c0109d48>] (vfs_write+0xb4/0x148)
> [ ? 85.290008] [<c0109d48>] (vfs_write+0xb4/0x148) from [<c0109fd0>] (sys_write+0x40/0x70)
> [ ? 85.298400] [<c0109fd0>] (sys_write+0x40/0x70) from [<c0013cc0>] (ret_fast_syscall+0x0/0x3c)
> -bash: echo: write error: Operation not permitted
>
> the way to trigger is:
>
>
> root at legolas:~# cd /sys/class/gpio/
> root at legolas:/sys/class/gpio# echo 2 > export
> root at legolas:/sys/class/gpio# echo 2 > unexport
> root at legolas:/sys/class/gpio# echo 2 > export
> root at legolas:/sys/class/gpio# cd gpio2/
> root at legolas:/sys/class/gpio/gpio2# echo 1 > value
Looks 'sysfs_lock' needn't to be held for unregister, so the patch below may
fix the problem.
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 17fdf4b..d773540 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -873,6 +873,7 @@ void gpio_unexport(unsigned gpio)
{
struct gpio_desc *desc;
int status = 0;
+ struct device *dev = NULL;
if (!gpio_is_valid(gpio)) {
status = -EINVAL;
@@ -884,19 +885,20 @@ void gpio_unexport(unsigned gpio)
desc = &gpio_desc[gpio];
if (test_bit(FLAG_EXPORT, &desc->flags)) {
- struct device *dev = NULL;
dev = class_find_device(&gpio_class, NULL, desc, match_export);
if (dev) {
gpio_setup_irq(desc, dev, 0);
clear_bit(FLAG_EXPORT, &desc->flags);
- put_device(dev);
- device_unregister(dev);
} else
status = -ENODEV;
}
mutex_unlock(&sysfs_lock);
+ if (dev) {
+ device_unregister(dev);
+ put_device(dev);
+ }
done:
if (status)
pr_debug("%s: gpio%d status %d\n", __func__, gpio, status);
thanks,
--
Ming Lei
^ permalink raw reply related [flat|nested] 19+ 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
-1 siblings, 0 replies; 19+ 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] 19+ messages in thread
* Possible circular locking dependency (3.3-rc2)
@ 2012-02-15 18:54 ` Linus Walleij
0 siblings, 0 replies; 19+ messages in thread
From: Linus Walleij @ 2012-02-15 18:54 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Feb 13, 2012 at 3:53 PM, Ming Lei <tom.leiming@gmail.com> wrote:
> Looks 'sysfs_lock' needn't to be held for unregister, so the patch below may
> fix the problem.
Looks correct to me!
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Thanks,
Linus Walleij
^ permalink raw reply [flat|nested] 19+ 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
-1 siblings, 0 replies; 19+ 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] 19+ messages in thread
* Possible circular locking dependency (3.3-rc2)
@ 2012-02-15 20:07 ` Grant Likely
0 siblings, 0 replies; 19+ messages in thread
From: Grant Likely @ 2012-02-15 20:07 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 15, 2012 at 07:54:56PM +0100, Linus Walleij wrote:
> On Mon, Feb 13, 2012 at 3:53 PM, Ming Lei <tom.leiming@gmail.com> wrote:
>
> > Looks 'sysfs_lock' needn't to be held for unregister, so the patch below may
> > fix the problem.
>
> Looks correct to me!
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
Ming, can I have a proper Signed-off-by: line from you so I can apply this
patch?
Thanks,
g.
^ permalink raw reply [flat|nested] 19+ 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
-1 siblings, 0 replies; 19+ 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] 19+ messages in thread
* Possible circular locking dependency (3.3-rc2)
@ 2012-02-16 0:05 ` Ming Lei
0 siblings, 0 replies; 19+ messages in thread
From: Ming Lei @ 2012-02-16 0:05 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 16, 2012 at 4:07 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Wed, Feb 15, 2012 at 07:54:56PM +0100, Linus Walleij wrote:
>> On Mon, Feb 13, 2012 at 3:53 PM, Ming Lei <tom.leiming@gmail.com> wrote:
>>
>> > Looks 'sysfs_lock' needn't to be held for unregister, so the patch below may
>> > fix the problem.
>>
>> Looks correct to me!
>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
> Ming, can I have a proper Signed-off-by: line from you so I can apply this
> patch?
Sure, :-)
thanks
--
Ming Lei
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Possible circular locking dependency (3.3-rc2)
2012-02-13 14:53 ` Ming Lei
@ 2012-02-15 20:09 ` Grant Likely
-1 siblings, 0 replies; 19+ 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] 19+ messages in thread* Possible circular locking dependency (3.3-rc2)
@ 2012-02-15 20:09 ` Grant Likely
0 siblings, 0 replies; 19+ messages in thread
From: Grant Likely @ 2012-02-15 20:09 UTC (permalink / raw)
To: linux-arm-kernel
Felipe, can you confirm whether or not Ming's patch below solves your
problem?
g.
On Mon, Feb 13, 2012 at 10:53:20PM +0800, Ming Lei wrote:
> Hi,
>
> On Wed, Feb 8, 2012 at 8:41 PM, Felipe Balbi <balbi@ti.com> wrote:
> > Hi guys,
> >
> > I have just triggered the folllowing:
> >
> > [ ? 84.860321] ======================================================
> > [ ? 84.860321] [ INFO: possible circular locking dependency detected ]
> > [ ? 84.860321] 3.3.0-rc2-00026-ge4e8a39 #474 Not tainted
> > [ ? 84.860321] -------------------------------------------------------
> > [ ? 84.860321] bash/949 is trying to acquire lock:
> > [ ? 84.860321] ?(sysfs_lock){+.+.+.}, at: [<c0275358>] gpio_value_store+0x24/0xcc
> > [ ? 84.860321]
> > [ ? 84.860321] but task is already holding lock:
> > [ ? 84.860321] ?(s_active#22){++++.+}, at: [<c016996c>] sysfs_write_file+0xdc/0x184
> > [ ? 84.911468]
> > [ ? 84.911468] which lock already depends on the new lock.
> > [ ? 84.911468]
> > [ ? 84.920043]
> > [ ? 84.920043] the existing dependency chain (in reverse order) is:
> > [ ? 84.920043]
> > [ ? 84.927886] -> #1 (s_active#22){++++.+}:
> > [ ? 84.927886] ? ? ? ?[<c008f640>] check_prevs_add+0xdc/0x150
> > [ ? 84.927886] ? ? ? ?[<c008fc18>] validate_chain.clone.24+0x564/0x694
> > [ ? 84.927886] ? ? ? ?[<c0090cdc>] __lock_acquire+0x49c/0x980
> > [ ? 84.951660] ? ? ? ?[<c0091838>] lock_acquire+0x98/0x100
> > [ ? 84.951660] ? ? ? ?[<c016a8e8>] sysfs_deactivate+0xb0/0x100
> > [ ? 84.962982] ? ? ? ?[<c016b1b4>] sysfs_addrm_finish+0x2c/0x6c
> > [ ? 84.962982] ? ? ? ?[<c016b8bc>] sysfs_remove_dir+0x84/0x98
> > [ ? 84.962982] ? ? ? ?[<c02590d8>] kobject_del+0x10/0x78
> > [ ? 84.974670] ? ? ? ?[<c02c29e8>] device_del+0x140/0x170
> > [ ? 84.974670] ? ? ? ?[<c02c2a24>] device_unregister+0xc/0x18
> > [ ? 84.985382] ? ? ? ?[<c0276894>] gpio_unexport+0xbc/0xdc
> > [ ? 84.985382] ? ? ? ?[<c02768c8>] gpio_free+0x14/0xfc
> > [ ? 85.001708] ? ? ? ?[<c0276a28>] unexport_store+0x78/0x8c
> > [ ? 85.001708] ? ? ? ?[<c02c5af8>] class_attr_store+0x18/0x24
> > [ ? 85.007293] ? ? ? ?[<c0169990>] sysfs_write_file+0x100/0x184
> > [ ? 85.018981] ? ? ? ?[<c0109d48>] vfs_write+0xb4/0x148
> > [ ? 85.018981] ? ? ? ?[<c0109fd0>] sys_write+0x40/0x70
> > [ ? 85.018981] ? ? ? ?[<c0013cc0>] ret_fast_syscall+0x0/0x3c
> > [ ? 85.035003]
> > [ ? 85.035003] -> #0 (sysfs_lock){+.+.+.}:
> > [ ? 85.035003] ? ? ? ?[<c008f54c>] check_prev_add+0x680/0x698
> > [ ? 85.035003] ? ? ? ?[<c008f640>] check_prevs_add+0xdc/0x150
> > [ ? 85.052093] ? ? ? ?[<c008fc18>] validate_chain.clone.24+0x564/0x694
> > [ ? 85.052093] ? ? ? ?[<c0090cdc>] __lock_acquire+0x49c/0x980
> > [ ? 85.052093] ? ? ? ?[<c0091838>] lock_acquire+0x98/0x100
> > [ ? 85.069885] ? ? ? ?[<c047e280>] mutex_lock_nested+0x3c/0x2f4
> > [ ? 85.069885] ? ? ? ?[<c0275358>] gpio_value_store+0x24/0xcc
> > [ ? 85.069885] ? ? ? ?[<c02c18dc>] dev_attr_store+0x18/0x24
> > [ ? 85.087158] ? ? ? ?[<c0169990>] sysfs_write_file+0x100/0x184
> > [ ? 85.087158] ? ? ? ?[<c0109d48>] vfs_write+0xb4/0x148
> > [ ? 85.098297] ? ? ? ?[<c0109fd0>] sys_write+0x40/0x70
> > [ ? 85.098297] ? ? ? ?[<c0013cc0>] ret_fast_syscall+0x0/0x3c
> > [ ? 85.109069]
> > [ ? 85.109069] other info that might help us debug this:
> > [ ? 85.109069]
> > [ ? 85.117462] ?Possible unsafe locking scenario:
> > [ ? 85.117462]
> > [ ? 85.117462] ? ? ? ?CPU0 ? ? ? ? ? ? ? ? ? ?CPU1
> > [ ? 85.128417] ? ? ? ?---- ? ? ? ? ? ? ? ? ? ?----
> > [ ? 85.128417] ? lock(s_active#22);
> > [ ? 85.128417] ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?lock(sysfs_lock);
> > [ ? 85.128417] ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?lock(s_active#22);
> > [ ? 85.142486] ? lock(sysfs_lock);
> > [ ? 85.151794]
> > [ ? 85.151794] ?*** DEADLOCK ***
> > [ ? 85.151794]
> > [ ? 85.151794] 2 locks held by bash/949:
> > [ ? 85.158020] ?#0: ?(&buffer->mutex){+.+.+.}, at: [<c01698b8>] sysfs_write_file+0x28/0x184
> > [ ? 85.170349] ?#1: ?(s_active#22){++++.+}, at: [<c016996c>] sysfs_write_file+0xdc/0x184
> > [ ? 85.170349]
> > [ ? 85.178588] stack backtrace:
> > [ ? 85.178588] [<c001b824>] (unwind_backtrace+0x0/0xf0) from [<c008de64>] (print_circular_bug+0x100/0x114)
> > [ ? 85.193023] [<c008de64>] (print_circular_bug+0x100/0x114) from [<c008f54c>] (check_prev_add+0x680/0x698)
> > [ ? 85.193023] [<c008f54c>] (check_prev_add+0x680/0x698) from [<c008f640>] (check_prevs_add+0xdc/0x150)
> > [ ? 85.212524] [<c008f640>] (check_prevs_add+0xdc/0x150) from [<c008fc18>] (validate_chain.clone.24+0x564/0x694)
> > [ ? 85.212524] [<c008fc18>] (validate_chain.clone.24+0x564/0x694) from [<c0090cdc>] (__lock_acquire+0x49c/0x980)
> > [ ? 85.233306] [<c0090cdc>] (__lock_acquire+0x49c/0x980) from [<c0091838>] (lock_acquire+0x98/0x100)
> > [ ? 85.233306] [<c0091838>] (lock_acquire+0x98/0x100) from [<c047e280>] (mutex_lock_nested+0x3c/0x2f4)
> > [ ? 85.242614] [<c047e280>] (mutex_lock_nested+0x3c/0x2f4) from [<c0275358>] (gpio_value_store+0x24/0xcc)
> > [ ? 85.261840] [<c0275358>] (gpio_value_store+0x24/0xcc) from [<c02c18dc>] (dev_attr_store+0x18/0x24)
> > [ ? 85.261840] [<c02c18dc>] (dev_attr_store+0x18/0x24) from [<c0169990>] (sysfs_write_file+0x100/0x184)
> > [ ? 85.271240] [<c0169990>] (sysfs_write_file+0x100/0x184) from [<c0109d48>] (vfs_write+0xb4/0x148)
> > [ ? 85.290008] [<c0109d48>] (vfs_write+0xb4/0x148) from [<c0109fd0>] (sys_write+0x40/0x70)
> > [ ? 85.298400] [<c0109fd0>] (sys_write+0x40/0x70) from [<c0013cc0>] (ret_fast_syscall+0x0/0x3c)
> > -bash: echo: write error: Operation not permitted
> >
> > the way to trigger is:
> >
> >
> > root at legolas:~# cd /sys/class/gpio/
> > root at legolas:/sys/class/gpio# echo 2 > export
> > root at legolas:/sys/class/gpio# echo 2 > unexport
> > root at legolas:/sys/class/gpio# echo 2 > export
> > root at legolas:/sys/class/gpio# cd gpio2/
> > root at legolas:/sys/class/gpio/gpio2# echo 1 > value
>
> Looks 'sysfs_lock' needn't to be held for unregister, so the patch below may
> fix the problem.
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 17fdf4b..d773540 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -873,6 +873,7 @@ void gpio_unexport(unsigned gpio)
> {
> struct gpio_desc *desc;
> int status = 0;
> + struct device *dev = NULL;
>
> if (!gpio_is_valid(gpio)) {
> status = -EINVAL;
> @@ -884,19 +885,20 @@ void gpio_unexport(unsigned gpio)
> desc = &gpio_desc[gpio];
>
> if (test_bit(FLAG_EXPORT, &desc->flags)) {
> - struct device *dev = NULL;
>
> dev = class_find_device(&gpio_class, NULL, desc, match_export);
> if (dev) {
> gpio_setup_irq(desc, dev, 0);
> clear_bit(FLAG_EXPORT, &desc->flags);
> - put_device(dev);
> - device_unregister(dev);
> } else
> status = -ENODEV;
> }
>
> mutex_unlock(&sysfs_lock);
> + if (dev) {
> + device_unregister(dev);
> + put_device(dev);
> + }
> done:
> if (status)
> pr_debug("%s: gpio%d status %d\n", __func__, gpio, status);
>
>
> thanks,
> --
> Ming Lei
^ permalink raw reply [flat|nested] 19+ 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
-1 siblings, 0 replies; 19+ 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] 19+ messages in thread* Possible circular locking dependency (3.3-rc2)
@ 2012-02-20 8:07 ` Thomas Weber
0 siblings, 0 replies; 19+ messages in thread
From: Thomas Weber @ 2012-02-20 8:07 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
I applied the patch from Ming, but got also an error.
I am ccing Neil, because I also applied some patches from him.
Regards,
Thomas
> [ 6.229370] ======================================================
> [ 6.235870] [ INFO: possible circular locking dependency detected ]
> [ 6.242431] 3.3.0-rc4-00020-ga02b31a #10 Not tainted
> [ 6.247650] -------------------------------------------------------
> [ 6.254241] udevadm/596 is trying to acquire lock:
> [ 6.259277] (&dev->mutex#2){+.+.+.}, at: [<c0308af0>] w1_bq27000_read+0x1c/0x48
> [ 6.267120]
> [ 6.267120] but task is already holding lock:
> [ 6.273254] (s_active#11){++++.+}, at: [<c01463d4>] sysfs_write_file+0xdc/0x180
> [ 6.281097]
> [ 6.281127] which lock already depends on the new lock.
> [ 6.281127]
> [ 6.289703]
> [ 6.289703] the existing dependency chain (in reverse order) is:
> [ 6.297576]
> [ 6.297576] -> #1 (s_active#11){++++.+}:
> [ 6.303283] [<c007b3c8>] lock_acquire+0xa0/0x128
> [ 6.308807] [<c0147b50>] sysfs_addrm_finish+0xf4/0x148
> [ 6.314880] [<c0146184>] sysfs_hash_and_remove+0x4c/0x88
> [ 6.321136] [<c0146cec>] sysfs_remove_file+0x30/0x38
> [ 6.326995] [<c0275bec>] device_del+0xf0/0x17c
> [ 6.332336] [<c0275c84>] device_unregister+0xc/0x18
> [ 6.338104] [<c0306b28>] w1_slave_detach+0xac/0xcc
> [ 6.343811] [<c0306e5c>] w1_reconnect_slaves+0xc0/0x10c
> [ 6.349945] [<c0307924>] w1_register_family+0x90/0xa0
> [ 6.355926] [<c0008760>] do_one_initcall+0x34/0x174
> [ 6.361694] [<c054980c>] kernel_init+0x94/0x11c
> [ 6.367126] [<c00148b0>] kernel_thread_exit+0x0/0x8
> [ 6.372924]
> [ 6.372924] -> #0 (&dev->mutex#2){+.+.+.}:
> [ 6.378845] [<c007a980>] __lock_acquire+0x1678/0x1ad4
> [ 6.384826] [<c007b3c8>] lock_acquire+0xa0/0x128
> [ 6.390319] [<c03c7b24>] mutex_lock_nested+0x48/0x2bc
> [ 6.396301] [<c0308af0>] w1_bq27000_read+0x1c/0x48
> [ 6.401977] [<c03098d4>] bq27000_read_platform+0x2c/0x124
> [ 6.408325] [<c030a004>] bq27x00_battery_get_property+0x1cc/0x3cc
> [ 6.415374] [<c0309154>] power_supply_show_property+0x4c/0x224
> [ 6.422180] [<c0309468>] power_supply_uevent+0xe4/0x224
> [ 6.428314] [<c0276b60>] dev_uevent+0xb4/0x170
> [ 6.433654] [<c01f4b84>] kobject_uevent_env+0x1d8/0x478
> [ 6.439819] [<c027603c>] store_uevent+0x50/0x54
> [ 6.445220] [<c0274f58>] dev_attr_store+0x18/0x24
> [ 6.450805] [<c01463f8>] sysfs_write_file+0x100/0x180
> [ 6.456787] [<c00e96a0>] vfs_write+0xa8/0x138
> [ 6.462036] [<c00e9910>] sys_write+0x40/0x6c
> [ 6.467163] [<c00138e0>] ret_fast_syscall+0x0/0x3c
> [ 6.472869]
> [ 6.472869] other info that might help us debug this:
> [ 6.472900]
> [ 6.481292] Possible unsafe locking scenario:
> [ 6.481292]
> [ 6.487518] CPU0 CPU1
> [ 6.492248] ---- ----
> [ 6.497009] lock(s_active#11);
> [ 6.500427] lock(&dev->mutex#2);
> [ 6.506683] lock(s_active#11);
> [ 6.512756] lock(&dev->mutex#2);
> [ 6.516357]
> [ 6.516357] *** DEADLOCK ***
> [ 6.516357]
> [ 6.522583] 2 locks held by udevadm/596:
> [ 6.526702] #0: (&buffer->mutex){+.+.+.}, at: [<c0146320>] sysfs_write_file+0x28/0x180
> [ 6.535278] #1: (s_active#11){++++.+}, at: [<c01463d4>] sysfs_write_file+0xdc/0x180
> [ 6.543579]
> [ 6.543579]
> [ 6.543579] stack backtrace:
> [ 6.548217] [<c0019e9c>] (unwind_backtrace+0x0/0xf8) from [<c03c3544>] (print_circular_bug+0x2c8/0x2d4)
> [ 6.558105] [<c03c3544>] (print_circular_bug+0x2c8/0x2d4) from [<c007a980>] (__lock_acquire+0x1678/0x1ad4)
> [ 6.568267] [<c007a980>] (__lock_acquire+0x1678/0x1ad4) from [<c007b3c8>] (lock_acquire+0xa0/0x128)
> [ 6.577789] [<c007b3c8>] (lock_acquire+0xa0/0x128) from [<c03c7b24>] (mutex_lock_nested+0x48/0x2bc)
> [ 6.587310] [<c03c7b24>] (mutex_lock_nested+0x48/0x2bc) from [<c0308af0>] (w1_bq27000_read+0x1c/0x48)
> [ 6.597015] [<c0308af0>] (w1_bq27000_read+0x1c/0x48) from [<c03098d4>] (bq27000_read_platform+0x2c/0x124)
> [ 6.607086] [<c03098d4>] (bq27000_read_platform+0x2c/0x124) from [<c030a004>] (bq27x00_battery_get_property+0x1cc/0x3cc)
> [ 6.618499] [<c030a004>] (bq27x00_battery_get_property+0x1cc/0x3cc) from [<c0309154>] (power_supply_show_property+0x4c/0x224)
> [ 6.630401] [<c0309154>] (power_supply_show_property+0x4c/0x224) from [<c0309468>] (power_supply_uevent+0xe4/0x224)
> [ 6.641357] [<c0309468>] (power_supply_uevent+0xe4/0x224) from [<c0276b60>] (dev_uevent+0xb4/0x170)
> [ 6.650909] [<c0276b60>] (dev_uevent+0xb4/0x170) from [<c01f4b84>] (kobject_uevent_env+0x1d8/0x478)
> [ 6.660430] [<c01f4b84>] (kobject_uevent_env+0x1d8/0x478) from [<c027603c>] (store_uevent+0x50/0x54)
> [ 6.670013] [<c027603c>] (store_uevent+0x50/0x54) from [<c0274f58>] (dev_attr_store+0x18/0x24)
> [ 6.679107] [<c0274f58>] (dev_attr_store+0x18/0x24) from [<c01463f8>] (sysfs_write_file+0x100/0x180)
> [ 6.688720] [<c01463f8>] (sysfs_write_file+0x100/0x180) from [<c00e96a0>] (vfs_write+0xa8/0x138)
> [ 6.697967] [<c00e96a0>] (vfs_write+0xa8/0x138) from [<c00e9910>] (sys_write+0x40/0x6c)
> [ 6.706390] [<c00e9910>] (sys_write+0x40/0x6c) from [<c00138e0>] (ret_fast_syscall+0x0/0x3c)
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: Possible circular locking dependency (3.3-rc2)
2012-02-20 8:07 ` Thomas Weber
@ 2012-02-20 9:08 ` NeilBrown
-1 siblings, 0 replies; 19+ 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] 19+ messages in thread* Possible circular locking dependency (3.3-rc2)
@ 2012-02-20 9:08 ` NeilBrown
0 siblings, 0 replies; 19+ messages in thread
From: NeilBrown @ 2012-02-20 9:08 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 20 Feb 2012 09:07:42 +0100 Thomas Weber
<thomas.weber.linux@googlemail.com> wrote:
> Hello,
>
> I applied the patch from Ming, but got also an error.
> I am ccing Neil, because I also applied some patches from him.
That looks like it is the third of the three patches I sent.
I needed some locking and there was a mutex available that seemed to be
available so I used it. Apparently it causes problems.
I don't think I ever saw that myself ... I wonder why.
There is already a dependency between the mutex I used and s_active
in sysfs. I guess that means I'll have to create a new lock just for
the purpose of keeping two threads from using the w1 bus at the same time...
Apart from this - which is just a warning, though maybe it could become a
real deadlock - is the bq27000 now working for you?
NeilBrown
>
> Regards,
> Thomas
>
> > [ 6.229370] ======================================================
> > [ 6.235870] [ INFO: possible circular locking dependency detected ]
> > [ 6.242431] 3.3.0-rc4-00020-ga02b31a #10 Not tainted
> > [ 6.247650] -------------------------------------------------------
> > [ 6.254241] udevadm/596 is trying to acquire lock:
> > [ 6.259277] (&dev->mutex#2){+.+.+.}, at: [<c0308af0>] w1_bq27000_read+0x1c/0x48
> > [ 6.267120]
> > [ 6.267120] but task is already holding lock:
> > [ 6.273254] (s_active#11){++++.+}, at: [<c01463d4>] sysfs_write_file+0xdc/0x180
> > [ 6.281097]
> > [ 6.281127] which lock already depends on the new lock.
> > [ 6.281127]
> > [ 6.289703]
> > [ 6.289703] the existing dependency chain (in reverse order) is:
> > [ 6.297576]
> > [ 6.297576] -> #1 (s_active#11){++++.+}:
> > [ 6.303283] [<c007b3c8>] lock_acquire+0xa0/0x128
> > [ 6.308807] [<c0147b50>] sysfs_addrm_finish+0xf4/0x148
> > [ 6.314880] [<c0146184>] sysfs_hash_and_remove+0x4c/0x88
> > [ 6.321136] [<c0146cec>] sysfs_remove_file+0x30/0x38
> > [ 6.326995] [<c0275bec>] device_del+0xf0/0x17c
> > [ 6.332336] [<c0275c84>] device_unregister+0xc/0x18
> > [ 6.338104] [<c0306b28>] w1_slave_detach+0xac/0xcc
> > [ 6.343811] [<c0306e5c>] w1_reconnect_slaves+0xc0/0x10c
> > [ 6.349945] [<c0307924>] w1_register_family+0x90/0xa0
> > [ 6.355926] [<c0008760>] do_one_initcall+0x34/0x174
> > [ 6.361694] [<c054980c>] kernel_init+0x94/0x11c
> > [ 6.367126] [<c00148b0>] kernel_thread_exit+0x0/0x8
> > [ 6.372924]
> > [ 6.372924] -> #0 (&dev->mutex#2){+.+.+.}:
> > [ 6.378845] [<c007a980>] __lock_acquire+0x1678/0x1ad4
> > [ 6.384826] [<c007b3c8>] lock_acquire+0xa0/0x128
> > [ 6.390319] [<c03c7b24>] mutex_lock_nested+0x48/0x2bc
> > [ 6.396301] [<c0308af0>] w1_bq27000_read+0x1c/0x48
> > [ 6.401977] [<c03098d4>] bq27000_read_platform+0x2c/0x124
> > [ 6.408325] [<c030a004>] bq27x00_battery_get_property+0x1cc/0x3cc
> > [ 6.415374] [<c0309154>] power_supply_show_property+0x4c/0x224
> > [ 6.422180] [<c0309468>] power_supply_uevent+0xe4/0x224
> > [ 6.428314] [<c0276b60>] dev_uevent+0xb4/0x170
> > [ 6.433654] [<c01f4b84>] kobject_uevent_env+0x1d8/0x478
> > [ 6.439819] [<c027603c>] store_uevent+0x50/0x54
> > [ 6.445220] [<c0274f58>] dev_attr_store+0x18/0x24
> > [ 6.450805] [<c01463f8>] sysfs_write_file+0x100/0x180
> > [ 6.456787] [<c00e96a0>] vfs_write+0xa8/0x138
> > [ 6.462036] [<c00e9910>] sys_write+0x40/0x6c
> > [ 6.467163] [<c00138e0>] ret_fast_syscall+0x0/0x3c
> > [ 6.472869]
> > [ 6.472869] other info that might help us debug this:
> > [ 6.472900]
> > [ 6.481292] Possible unsafe locking scenario:
> > [ 6.481292]
> > [ 6.487518] CPU0 CPU1
> > [ 6.492248] ---- ----
> > [ 6.497009] lock(s_active#11);
> > [ 6.500427] lock(&dev->mutex#2);
> > [ 6.506683] lock(s_active#11);
> > [ 6.512756] lock(&dev->mutex#2);
> > [ 6.516357]
> > [ 6.516357] *** DEADLOCK ***
> > [ 6.516357]
> > [ 6.522583] 2 locks held by udevadm/596:
> > [ 6.526702] #0: (&buffer->mutex){+.+.+.}, at: [<c0146320>] sysfs_write_file+0x28/0x180
> > [ 6.535278] #1: (s_active#11){++++.+}, at: [<c01463d4>] sysfs_write_file+0xdc/0x180
> > [ 6.543579]
> > [ 6.543579]
> > [ 6.543579] stack backtrace:
> > [ 6.548217] [<c0019e9c>] (unwind_backtrace+0x0/0xf8) from [<c03c3544>] (print_circular_bug+0x2c8/0x2d4)
> > [ 6.558105] [<c03c3544>] (print_circular_bug+0x2c8/0x2d4) from [<c007a980>] (__lock_acquire+0x1678/0x1ad4)
> > [ 6.568267] [<c007a980>] (__lock_acquire+0x1678/0x1ad4) from [<c007b3c8>] (lock_acquire+0xa0/0x128)
> > [ 6.577789] [<c007b3c8>] (lock_acquire+0xa0/0x128) from [<c03c7b24>] (mutex_lock_nested+0x48/0x2bc)
> > [ 6.587310] [<c03c7b24>] (mutex_lock_nested+0x48/0x2bc) from [<c0308af0>] (w1_bq27000_read+0x1c/0x48)
> > [ 6.597015] [<c0308af0>] (w1_bq27000_read+0x1c/0x48) from [<c03098d4>] (bq27000_read_platform+0x2c/0x124)
> > [ 6.607086] [<c03098d4>] (bq27000_read_platform+0x2c/0x124) from [<c030a004>] (bq27x00_battery_get_property+0x1cc/0x3cc)
> > [ 6.618499] [<c030a004>] (bq27x00_battery_get_property+0x1cc/0x3cc) from [<c0309154>] (power_supply_show_property+0x4c/0x224)
> > [ 6.630401] [<c0309154>] (power_supply_show_property+0x4c/0x224) from [<c0309468>] (power_supply_uevent+0xe4/0x224)
> > [ 6.641357] [<c0309468>] (power_supply_uevent+0xe4/0x224) from [<c0276b60>] (dev_uevent+0xb4/0x170)
> > [ 6.650909] [<c0276b60>] (dev_uevent+0xb4/0x170) from [<c01f4b84>] (kobject_uevent_env+0x1d8/0x478)
> > [ 6.660430] [<c01f4b84>] (kobject_uevent_env+0x1d8/0x478) from [<c027603c>] (store_uevent+0x50/0x54)
> > [ 6.670013] [<c027603c>] (store_uevent+0x50/0x54) from [<c0274f58>] (dev_attr_store+0x18/0x24)
> > [ 6.679107] [<c0274f58>] (dev_attr_store+0x18/0x24) from [<c01463f8>] (sysfs_write_file+0x100/0x180)
> > [ 6.688720] [<c01463f8>] (sysfs_write_file+0x100/0x180) from [<c00e96a0>] (vfs_write+0xa8/0x138)
> > [ 6.697967] [<c00e96a0>] (vfs_write+0xa8/0x138) from [<c00e9910>] (sys_write+0x40/0x6c)
> > [ 6.706390] [<c00e9910>] (sys_write+0x40/0x6c) from [<c00138e0>] (ret_fast_syscall+0x0/0x3c)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120220/16eb3302/attachment.sig>
^ permalink raw reply [flat|nested] 19+ messages in thread