On Thu, 22 Jun 2006 03:40:36 -0400
"Brown, Len" <[email protected]> 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-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
