Messages in this thread | | | Date | Wed, 21 Jun 2006 21:59:46 -0700 | From | Andrew Morton <> | Subject | Re: 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/
| |