| 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@xxxxxxxxxxxxxxxxxxxxxxxx> |
| References: | <20060704004116.GA7612@xxxxxxxxxxxxxxxxxxxxxx> <20060704011858.GG1605@xxxxxxxxxxxxxxxx> <20060704112503.H1495869@xxxxxxxxxxxxxxxxxxxxxxxx> <20060704063225.GA2752@xxxxxxx> <20060704084143.GA12931@xxxxxxx> <20060704191100.C1497438@xxxxxxxxxxxxxxxxxxxxxxxx> |
| 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
|
| Previous by Date: | Re: [LOCKDEP] xfs: possible recursive locking detected, Nathan Scott |
|---|---|
| Next by Date: | Re: [LOCKDEP] xfs: possible recursive locking detected, Ingo Molnar |
| Previous by Thread: | Re: [LOCKDEP] xfs: possible recursive locking detected, Nathan Scott |
| Next by Thread: | Re: [LOCKDEP] xfs: possible recursive locking detected, Nathan Scott |
| Indexes: | [Date] [Thread] [Top] [All Lists] |