xfs
[Top] [All Lists]

Re: [LOCKDEP] xfs: possible recursive locking detected

To: Nathan Scott <nathans@xxxxxxx>
Subject: Re: [LOCKDEP] xfs: possible recursive locking detected
From: Ingo Molnar <mingo@xxxxxxx>
Date: Tue, 4 Jul 2006 11:12:47 +0200
Cc: Alexey Dobriyan <adobriyan@xxxxxxxxx>, Matthew Wilcox <matthew@xxxxxx>, linux-fsdevel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx, Arjan van de Ven <arjan@xxxxxxxxxxxxx>
In-reply-to: <20060704191100.C1497438@wobbly.melbourne.sgi.com>
References: <20060704004116.GA7612@martell.zuzino.mipt.ru> <20060704011858.GG1605@parisc-linux.org> <20060704112503.H1495869@wobbly.melbourne.sgi.com> <20060704063225.GA2752@elte.hu> <20060704084143.GA12931@elte.hu> <20060704191100.C1497438@wobbly.melbourne.sgi.com>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
* Nathan Scott <nathans@xxxxxxx> wrote:

> > i'd really suggest to clean this up and to convert:
> >     xfs_ilock(ip, XFS_ILOCK_EXCL);
> > to:
> >     down_write(&ip->i_lock);
> > and:
> >     xfs_iunlock(ip, XFS_ILOCK_EXCL);
> > to:
> >     up_write(&ip->i_lock);
> > and eliminate all those layers of indirection.
> 
> 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.

        Ingo


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