lkml.org 
[lkml]   [2006]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.17-mm1 - possible recursive locking detected
On Thu, 22 Jun 2006 00:28:56 -0400
"Brown, Len" <len.brown@intel.com> wrote:

> >It looks like an ACPI problem.
>
> Thanks for the note, and the .config, I reproduced it here.
>
> CONFIG_LOCKDEP complains about this sequence:
>
> ...
> <presumed previous acquire/release acpi_gbl_hardware_lock>
> ...
> acpi_ev_gpe_detect()
> spin_lock_irqsave(acpi_gbl_gpe_lock,)
>
> spin_lock_irqsave(acpi_gbl_hardware_lock,) <stack trace is on
> this acquire>
> spin_lock_irqrestore(acpi_gbl_hardware_lock,)
>
> ...
>
> spin_lock_irqrestore(acpi_gbl_gpe_lock)
>
> It complains about this only the 1st time, even though
> this same code sequence runs for every (subsequent) ACPI interrupt.
>
> The intent of the arrangement is that acpi_gbl_hardware_lock is for very
> small critical sections around RMW hardware register access.
> It can be acquired with or without other locks held, but
> nothing else is acquired when it is held.
>
> Nothing jumps out at me as incorrect above, so
> at this point it looks like a CONFIG_LOCKDEP artifact --
> but lets ask the experts:-)

Yes, lockdep uses the callsite of spin_lock_init() to detect the "type" of
a lock.

But the ACPI obfuscation layers use the same spin_lock_init() site to
initialise two not-the-same locks, so lockdep decides those two locks are
of the same "type" and gets confused.

We had earlier decided to remove that ACPI code which kmallocs a single
spinlock. When that's done, lockdep will become unconfused.

AFACIT it's all used for just two statically allocated locks anwyay.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-06-22 07:02    [W:0.058 / U:0.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site