Re: 2.6.17-mm1 - possible recursive locking detected

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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
Please read the FAQ at

[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]
  Powered by Linux