On Saturday 29 December 2007, Alan Stern wrote:
> lockdep warns whenever a task acquires a mutex while holding another
> mutex of the same kind (that is, the same member in another structure
> of the same type). But there are lots of places where the kernel needs
> to acquire dev->sem for one device while already holding
> dev->parent->sem.
Not just devices. I've seen the same issue with genirq when
enabling or disabling wakeup: while holding irq_desc[354].lock
it must also acquire the parent IRQ's irq_desc[37].lock so it
can update that parent IRQ's wake flag ... because the wake
signal goes from the child up to the parent up to the logic
that kicks the clock framework and thence the CPU, and software
must enable at least some of those paths by hand.
And lockdep says "[ INFO: possible recursive locking detected ]".
But the analysis is "ignore that one, it's a false alarm".
> There's no way to remove these, which means there's
> no way to prevent lockdep from issuing a warning.
There may be no *efficient* way to do that. If it tracked
every lock individually these false alarms could go away;
but that would increase the overhead to create and destroy
such locks too.
Such tradeoffs are what make it Engineering, not Science. ;)
- Dave
--
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]
