Re: 2.6.17-mm1 - possible recursive locking detected

[Andrew Morton <akpm@osdl.org>]

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/