On Thu, 22 Jun 2006 03:40:36 -0400 "Brown, Len" <len.brown@xxxxxxxxx> wrote: > >> 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. > > interesting definition of "type". I guess it works > in practice or others would be complaining... It works out that way, yes. > >We had earlier decided to remove that ACPI code which kmallocs a single > >spinlock. When that's done, lockdep will become unconfused. > > Yes, that change is already on the way. Is good. > The key thing here is that our recent changes in > how the locks are _used_ is okay -- and I think it is. Well. We don't know that. We just know that this report of unokayness wasn't right. With Ingo's Linux-only patch we're in a position to verify that the locking is probably OK. - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
