* 2.6.23-rc2-mm1 -- INFO: possible circular locking dependency detected
@ 2007-08-09 20:24 Miles Lane
2007-08-09 20:58 ` Andrew Morton
0 siblings, 1 reply; 5+ messages in thread
From: Miles Lane @ 2007-08-09 20:24 UTC (permalink / raw)
To: Andrew Morton, LKML, ACPI Devel Maling List
[ INFO: possible circular locking dependency detected ]
2.6.23-rc2-mm1 #7
-------------------------------------------------------
kacpid/53 is trying to acquire lock:
(&ec->lock){--..}, at: [<c03031a7>] mutex_lock+0x1c/0x1f
but task is already holding lock:
(&dpc->work){--..}, at: [<c012689d>] run_workqueue+0xa0/0x182
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&dpc->work){--..}:
[<c0133d24>] __lock_acquire+0x9a6/0xb6f
[<c0133f4e>] lock_acquire+0x61/0x7d
[<c01268b2>] run_workqueue+0xb5/0x182
[<c01271a9>] worker_thread+0xb7/0xc2
[<c01296c4>] kthread+0x39/0x61
[<c0104913>] kernel_thread_helper+0x7/0x10
[<ffffffff>] 0xffffffff
-> #1 (kacpid){--..}:
[<c0133d24>] __lock_acquire+0x9a6/0xb6f
[<c0133f4e>] lock_acquire+0x61/0x7d
[<c0126f62>] flush_workqueue+0x2d/0x4f
[<c01e85e0>] acpi_os_wait_events_complete+0xd/0xf
[<c01ef605>] acpi_remove_gpe_handler+0x7b/0xdd
[<c0205981>] ec_remove_handlers+0x26/0x29
[<c02062b4>] acpi_ec_add+0x8f/0x13e
[<c0205477>] acpi_device_probe+0x3e/0xdb
[<c023c4c8>] driver_probe_device+0xd7/0x14d
[<c023c652>] __driver_attach+0x6a/0xa1
[<c023baaa>] bus_for_each_dev+0x36/0x5b
[<c023c32e>] driver_attach+0x14/0x16
[<c023bd7e>] bus_add_driver+0x70/0x16c
[<c023c82d>] driver_register+0x60/0x65
[<c020577b>] acpi_bus_register_driver+0x3a/0x3c
[<c04292e4>] acpi_ec_init+0x36/0x55
[<c0416650>] kernel_init+0xc5/0x20f
[<c0104913>] kernel_thread_helper+0x7/0x10
[<ffffffff>] 0xffffffff
-> #0 (&ec->lock){--..}:
[<c0133c44>] __lock_acquire+0x8c6/0xb6f
[<c0133f4e>] lock_acquire+0x61/0x7d
[<c0303006>] __mutex_lock_slowpath+0xbc/0x241
[<c03031a7>] mutex_lock+0x1c/0x1f
[<c0205bbd>] acpi_ec_transaction+0x65/0x1c1
[<c0205d44>] acpi_ec_gpe_query+0x2b/0xab
[<c01e8602>] acpi_os_execute_deferred+0x20/0x31
[<c01268b7>] run_workqueue+0xba/0x182
[<c01271a9>] worker_thread+0xb7/0xc2
[<c01296c4>] kthread+0x39/0x61
[<c0104913>] kernel_thread_helper+0x7/0x10
[<ffffffff>] 0xffffffff
other info that might help us debug this:
2 locks held by kacpid/53:
#0: (kacpid){--..}, at: [<c0126882>] run_workqueue+0x85/0x182
#1: (&dpc->work){--..}, at: [<c012689d>] run_workqueue+0xa0/0x182
stack backtrace:
[<c0104c6a>] show_trace_log_lvl+0x12/0x25
[<c0105552>] show_trace+0xd/0x10
[<c0105656>] dump_stack+0x15/0x17
[<c0132580>] print_circular_bug_tail+0x5a/0x65
[<c0133c44>] __lock_acquire+0x8c6/0xb6f
[<c0133f4e>] lock_acquire+0x61/0x7d
[<c0303006>] __mutex_lock_slowpath+0xbc/0x241
[<c03031a7>] mutex_lock+0x1c/0x1f
[<c0205bbd>] acpi_ec_transaction+0x65/0x1c1
[<c0205d44>] acpi_ec_gpe_query+0x2b/0xab
[<c01e8602>] acpi_os_execute_deferred+0x20/0x31
[<c01268b7>] run_workqueue+0xba/0x182
[<c01271a9>] worker_thread+0xb7/0xc2
[<c01296c4>] kthread+0x39/0x61
[<c0104913>] kernel_thread_helper+0x7/0x10
=======================
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: 2.6.23-rc2-mm1 -- INFO: possible circular locking dependency detected
2007-08-09 20:24 2.6.23-rc2-mm1 -- INFO: possible circular locking dependency detected Miles Lane
@ 2007-08-09 20:58 ` Andrew Morton
2007-08-09 22:47 ` Alexey Starikovskiy
0 siblings, 1 reply; 5+ messages in thread
From: Andrew Morton @ 2007-08-09 20:58 UTC (permalink / raw)
To: Miles Lane; +Cc: LKML, ACPI Devel Maling List, Johannes Berg, Oleg Nesterov
On Thu, 9 Aug 2007 16:24:48 -0400
"Miles Lane" <miles.lane@gmail.com> wrote:
> [ INFO: possible circular locking dependency detected ]
> 2.6.23-rc2-mm1 #7
> -------------------------------------------------------
> kacpid/53 is trying to acquire lock:
> (&ec->lock){--..}, at: [<c03031a7>] mutex_lock+0x1c/0x1f
>
> but task is already holding lock:
> (&dpc->work){--..}, at: [<c012689d>] run_workqueue+0xa0/0x182
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #2 (&dpc->work){--..}:
> [<c0133d24>] __lock_acquire+0x9a6/0xb6f
> [<c0133f4e>] lock_acquire+0x61/0x7d
> [<c01268b2>] run_workqueue+0xb5/0x182
> [<c01271a9>] worker_thread+0xb7/0xc2
> [<c01296c4>] kthread+0x39/0x61
> [<c0104913>] kernel_thread_helper+0x7/0x10
> [<ffffffff>] 0xffffffff
>
> -> #1 (kacpid){--..}:
> [<c0133d24>] __lock_acquire+0x9a6/0xb6f
> [<c0133f4e>] lock_acquire+0x61/0x7d
> [<c0126f62>] flush_workqueue+0x2d/0x4f
> [<c01e85e0>] acpi_os_wait_events_complete+0xd/0xf
> [<c01ef605>] acpi_remove_gpe_handler+0x7b/0xdd
> [<c0205981>] ec_remove_handlers+0x26/0x29
> [<c02062b4>] acpi_ec_add+0x8f/0x13e
> [<c0205477>] acpi_device_probe+0x3e/0xdb
> [<c023c4c8>] driver_probe_device+0xd7/0x14d
> [<c023c652>] __driver_attach+0x6a/0xa1
> [<c023baaa>] bus_for_each_dev+0x36/0x5b
> [<c023c32e>] driver_attach+0x14/0x16
> [<c023bd7e>] bus_add_driver+0x70/0x16c
> [<c023c82d>] driver_register+0x60/0x65
> [<c020577b>] acpi_bus_register_driver+0x3a/0x3c
> [<c04292e4>] acpi_ec_init+0x36/0x55
> [<c0416650>] kernel_init+0xc5/0x20f
> [<c0104913>] kernel_thread_helper+0x7/0x10
> [<ffffffff>] 0xffffffff
>
> -> #0 (&ec->lock){--..}:
> [<c0133c44>] __lock_acquire+0x8c6/0xb6f
> [<c0133f4e>] lock_acquire+0x61/0x7d
> [<c0303006>] __mutex_lock_slowpath+0xbc/0x241
> [<c03031a7>] mutex_lock+0x1c/0x1f
> [<c0205bbd>] acpi_ec_transaction+0x65/0x1c1
> [<c0205d44>] acpi_ec_gpe_query+0x2b/0xab
> [<c01e8602>] acpi_os_execute_deferred+0x20/0x31
> [<c01268b7>] run_workqueue+0xba/0x182
> [<c01271a9>] worker_thread+0xb7/0xc2
> [<c01296c4>] kthread+0x39/0x61
> [<c0104913>] kernel_thread_helper+0x7/0x10
> [<ffffffff>] 0xffffffff
>
> other info that might help us debug this:
>
> 2 locks held by kacpid/53:
> #0: (kacpid){--..}, at: [<c0126882>] run_workqueue+0x85/0x182
> #1: (&dpc->work){--..}, at: [<c012689d>] run_workqueue+0xa0/0x182
>
> stack backtrace:
> [<c0104c6a>] show_trace_log_lvl+0x12/0x25
> [<c0105552>] show_trace+0xd/0x10
> [<c0105656>] dump_stack+0x15/0x17
> [<c0132580>] print_circular_bug_tail+0x5a/0x65
> [<c0133c44>] __lock_acquire+0x8c6/0xb6f
> [<c0133f4e>] lock_acquire+0x61/0x7d
> [<c0303006>] __mutex_lock_slowpath+0xbc/0x241
> [<c03031a7>] mutex_lock+0x1c/0x1f
> [<c0205bbd>] acpi_ec_transaction+0x65/0x1c1
> [<c0205d44>] acpi_ec_gpe_query+0x2b/0xab
> [<c01e8602>] acpi_os_execute_deferred+0x20/0x31
> [<c01268b7>] run_workqueue+0xba/0x182
> [<c01271a9>] worker_thread+0xb7/0xc2
> [<c01296c4>] kthread+0x39/0x61
> [<c0104913>] kernel_thread_helper+0x7/0x10
> =======================
Presumably the new debugging patches in -mm
(workqueue-debug-flushing-deadlocks-with-lockdep.patch and
workqueue-debug-work-related-deadlocks-with-lockdep.patch) think they have
found a potential deadlock in ACPI. I don't have time to pick through the
code to confirm that, but boy I'm good at adding cc's ;)
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: 2.6.23-rc2-mm1 -- INFO: possible circular locking dependency detected
2007-08-09 20:58 ` Andrew Morton
@ 2007-08-09 22:47 ` Alexey Starikovskiy
2007-08-10 9:47 ` Johannes Berg
0 siblings, 1 reply; 5+ messages in thread
From: Alexey Starikovskiy @ 2007-08-09 22:47 UTC (permalink / raw)
To: Andrew Morton
Cc: Miles Lane, LKML, ACPI Devel Maling List, Johannes Berg,
Oleg Nesterov
[-- Attachment #1: Type: text/plain, Size: 3823 bytes --]
Andrew Morton wrote:
> On Thu, 9 Aug 2007 16:24:48 -0400
> "Miles Lane" <miles.lane@gmail.com> wrote:
>
>> [ INFO: possible circular locking dependency detected ]
>> 2.6.23-rc2-mm1 #7
>> -------------------------------------------------------
>> kacpid/53 is trying to acquire lock:
>> (&ec->lock){--..}, at: [<c03031a7>] mutex_lock+0x1c/0x1f
>>
>> but task is already holding lock:
>> (&dpc->work){--..}, at: [<c012689d>] run_workqueue+0xa0/0x182
>>
>> which lock already depends on the new lock.
>>
>>
>> the existing dependency chain (in reverse order) is:
>>
>> -> #2 (&dpc->work){--..}:
>> [<c0133d24>] __lock_acquire+0x9a6/0xb6f
>> [<c0133f4e>] lock_acquire+0x61/0x7d
>> [<c01268b2>] run_workqueue+0xb5/0x182
>> [<c01271a9>] worker_thread+0xb7/0xc2
>> [<c01296c4>] kthread+0x39/0x61
>> [<c0104913>] kernel_thread_helper+0x7/0x10
>> [<ffffffff>] 0xffffffff
>>
>> -> #1 (kacpid){--..}:
>> [<c0133d24>] __lock_acquire+0x9a6/0xb6f
>> [<c0133f4e>] lock_acquire+0x61/0x7d
>> [<c0126f62>] flush_workqueue+0x2d/0x4f
>> [<c01e85e0>] acpi_os_wait_events_complete+0xd/0xf
>> [<c01ef605>] acpi_remove_gpe_handler+0x7b/0xdd
>> [<c0205981>] ec_remove_handlers+0x26/0x29
>> [<c02062b4>] acpi_ec_add+0x8f/0x13e
>> [<c0205477>] acpi_device_probe+0x3e/0xdb
>> [<c023c4c8>] driver_probe_device+0xd7/0x14d
>> [<c023c652>] __driver_attach+0x6a/0xa1
>> [<c023baaa>] bus_for_each_dev+0x36/0x5b
>> [<c023c32e>] driver_attach+0x14/0x16
>> [<c023bd7e>] bus_add_driver+0x70/0x16c
>> [<c023c82d>] driver_register+0x60/0x65
>> [<c020577b>] acpi_bus_register_driver+0x3a/0x3c
>> [<c04292e4>] acpi_ec_init+0x36/0x55
>> [<c0416650>] kernel_init+0xc5/0x20f
>> [<c0104913>] kernel_thread_helper+0x7/0x10
>> [<ffffffff>] 0xffffffff
>>
>> -> #0 (&ec->lock){--..}:
>> [<c0133c44>] __lock_acquire+0x8c6/0xb6f
>> [<c0133f4e>] lock_acquire+0x61/0x7d
>> [<c0303006>] __mutex_lock_slowpath+0xbc/0x241
>> [<c03031a7>] mutex_lock+0x1c/0x1f
>> [<c0205bbd>] acpi_ec_transaction+0x65/0x1c1
>> [<c0205d44>] acpi_ec_gpe_query+0x2b/0xab
>> [<c01e8602>] acpi_os_execute_deferred+0x20/0x31
>> [<c01268b7>] run_workqueue+0xba/0x182
>> [<c01271a9>] worker_thread+0xb7/0xc2
>> [<c01296c4>] kthread+0x39/0x61
>> [<c0104913>] kernel_thread_helper+0x7/0x10
>> [<ffffffff>] 0xffffffff
>>
>> other info that might help us debug this:
>>
>> 2 locks held by kacpid/53:
>> #0: (kacpid){--..}, at: [<c0126882>] run_workqueue+0x85/0x182
>> #1: (&dpc->work){--..}, at: [<c012689d>] run_workqueue+0xa0/0x182
>>
>> stack backtrace:
>> [<c0104c6a>] show_trace_log_lvl+0x12/0x25
>> [<c0105552>] show_trace+0xd/0x10
>> [<c0105656>] dump_stack+0x15/0x17
>> [<c0132580>] print_circular_bug_tail+0x5a/0x65
>> [<c0133c44>] __lock_acquire+0x8c6/0xb6f
>> [<c0133f4e>] lock_acquire+0x61/0x7d
>> [<c0303006>] __mutex_lock_slowpath+0xbc/0x241
>> [<c03031a7>] mutex_lock+0x1c/0x1f
>> [<c0205bbd>] acpi_ec_transaction+0x65/0x1c1
>> [<c0205d44>] acpi_ec_gpe_query+0x2b/0xab
>> [<c01e8602>] acpi_os_execute_deferred+0x20/0x31
>> [<c01268b7>] run_workqueue+0xba/0x182
>> [<c01271a9>] worker_thread+0xb7/0xc2
>> [<c01296c4>] kthread+0x39/0x61
>> [<c0104913>] kernel_thread_helper+0x7/0x10
>> =======================
>
> Presumably the new debugging patches in -mm
> (workqueue-debug-flushing-deadlocks-with-lockdep.patch and
> workqueue-debug-work-related-deadlocks-with-lockdep.patch) think they have
> found a potential deadlock in ACPI. I don't have time to pick through the
> code to confirm that, but boy I'm good at adding cc's ;)
Yep, it indeed may lock up... Here is a patch to avoid it
Thanks,
Alex.
[-- Attachment #2: remove_potential_deadlock_from_ec.patch --]
[-- Type: text/x-patch, Size: 714 bytes --]
ACPI EC: remove potential deadlock from EC.
From: Alexey Starikovskiy <astarikivskiy@suse.de>
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
---
drivers/acpi/ec.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index ceb7c3f..4b299fd 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -723,9 +723,7 @@ static int acpi_ec_add(struct acpi_device *device)
/* Check if we found the boot EC */
if (boot_ec) {
if (boot_ec->gpe == ec->gpe) {
- mutex_lock(&boot_ec->lock);
ec_remove_handlers(boot_ec);
- mutex_unlock(&boot_ec->lock);
mutex_destroy(&boot_ec->lock);
kfree(boot_ec);
first_ec = boot_ec = NULL;
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: 2.6.23-rc2-mm1 -- INFO: possible circular locking dependency detected
2007-08-09 22:47 ` Alexey Starikovskiy
@ 2007-08-10 9:47 ` Johannes Berg
0 siblings, 0 replies; 5+ messages in thread
From: Johannes Berg @ 2007-08-10 9:47 UTC (permalink / raw)
To: Alexey Starikovskiy
Cc: Andrew Morton, Miles Lane, LKML, ACPI Devel Maling List,
Oleg Nesterov
[-- Attachment #1: Type: text/plain, Size: 537 bytes --]
On Fri, 2007-08-10 at 02:47 +0400, Alexey Starikovskiy wrote:
> > Presumably the new debugging patches in -mm
> > (workqueue-debug-flushing-deadlocks-with-lockdep.patch and
> > workqueue-debug-work-related-deadlocks-with-lockdep.patch) think they have
> > found a potential deadlock in ACPI. I don't have time to pick through the
> > code to confirm that, but boy I'm good at adding cc's ;)
> Yep, it indeed may lock up... Here is a patch to avoid it
Cool. I'm impressed this stuff actually finds something :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: 2.6.23-rc2-mm1 -- INFO: possible circular locking dependency detected
@ 2007-08-10 9:47 ` Johannes Berg
0 siblings, 0 replies; 5+ messages in thread
From: Johannes Berg @ 2007-08-10 9:47 UTC (permalink / raw)
To: Alexey Starikovskiy
Cc: Andrew Morton, Miles Lane, LKML, ACPI Devel Maling List,
Oleg Nesterov
[-- Attachment #1: Type: text/plain, Size: 537 bytes --]
On Fri, 2007-08-10 at 02:47 +0400, Alexey Starikovskiy wrote:
> > Presumably the new debugging patches in -mm
> > (workqueue-debug-flushing-deadlocks-with-lockdep.patch and
> > workqueue-debug-work-related-deadlocks-with-lockdep.patch) think they have
> > found a potential deadlock in ACPI. I don't have time to pick through the
> > code to confirm that, but boy I'm good at adding cc's ;)
> Yep, it indeed may lock up... Here is a patch to avoid it
Cool. I'm impressed this stuff actually finds something :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2007-08-10 9:46 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-08-09 20:24 2.6.23-rc2-mm1 -- INFO: possible circular locking dependency detected Miles Lane
2007-08-09 20:58 ` Andrew Morton
2007-08-09 22:47 ` Alexey Starikovskiy
2007-08-10 9:47 ` Johannes Berg
2007-08-10 9:47 ` Johannes Berg
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.