xfs
[Top] [All Lists]

Re: [LOCKDEP] xfs: possible recursive locking detected

To: Ingo Molnar <mingo@xxxxxxx>
Subject: Re: [LOCKDEP] xfs: possible recursive locking detected
From: Nathan Scott <nathans@xxxxxxx>
Date: Wed, 5 Jul 2006 13:23:29 +1000
Cc: Alexey Dobriyan <adobriyan@xxxxxxxxx>, Matthew Wilcox <matthew@xxxxxx>, linux-fsdevel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx, Arjan van de Ven <arjan@xxxxxxxxxxxxx>
In-reply-to: <20060704091247.GA15982@xxxxxxx>; from mingo@xxxxxxx on Tue, Jul 04, 2006 at 11:12:47AM +0200
References: <20060704004116.GA7612@xxxxxxxxxxxxxxxxxxxxxx> <20060704011858.GG1605@xxxxxxxxxxxxxxxx> <20060704112503.H1495869@xxxxxxxxxxxxxxxxxxxxxxxx> <20060704063225.GA2752@xxxxxxx> <20060704084143.GA12931@xxxxxxx> <20060704191100.C1497438@xxxxxxxxxxxxxxxxxxxxxxxx> <20060704091247.GA15982@xxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.2.5i
On Tue, Jul 04, 2006 at 11:12:47AM +0200, Ingo Molnar wrote:
> * Nathan Scott <nathans@xxxxxxx> wrote:
> > That would be good, but it doesn't work for all situations 
> > unfortunately, and it would loose that debug-kernel sanity checking 
> > that we have in there which validates ilock/iolock ordering rules.
> 
> do you have anything in there that spinlock/mutex debugging or lockdep 
> does not catch? If yes then i'll add it to the generic lock debugging 
> code.

The thing we're catching automatically there is potential ordering
violations on the XFS inode iolock vs ilock.  I don't know if the
other methods can help us there too or not.

cheers.

-- 
Nathan


<Prev in Thread] Current Thread [Next in Thread>