On Tue, 25 Jan 2005 18:24:50 +0300, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > On Tue, 2005-01-25 at 14:23 +0000, Christoph Hellwig wrote: > > > > Also your locking is broken. sdev_lock sometimes nests outside > > > > sdev->lock and sometimes inside. Similarly dev->chain_lock nests > > > > inside dev->lock sometimes and sometimes outside. You really need > > > > a locking hiearchy document and the lockign should probably be > > > > simplified a lot. > > > > > > It is almost the same like after hand waving say that there is a wind. > > > > > > Each lock protect it's own data, sometimes it happens when other data is > > > locked, > > > sometimes not. Yes, probably interrupt handling can race, it requires > > > more review, > > > I will take a look. > > > > The thing I mention is called lock order reversal, which means a deadlock > > in most cases. I don't have the time to actual walk through all codepathes > > to tell you whether it can really happen and where, but it's a really > > big warning sign. > > No, it is not called lock order reversal. > > There are no places like > lock a > lock b > unlock a > unlock b > > and if they are, then I'm completely wrong. > > What you see is only following: > > place 1: > lock a > lock b > unlock b > lock c > unlock c > unlock a > > place 2: > lock b > lock a > unlock a > lock c > unlock c > unlock b
Ugh, now think about that: CPU0 CPU1 place1: place2: lock a lock b < guess what happens here :-) > lock b lock a ... ... - 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/
