Re: [LOCKDEP] xfs: possible recursive locking detected

[Nathan Scott <nathans@sgi.com>]

On Tue, Jul 04, 2006 at 11:57:43AM +0200, Ingo Molnar wrote:
> > Right... but that leaves plenty that don't, and they're not simple to 
> > change.  There are generic routines that need to be called from 
> > different contexts with different locking requirements (xfs_iget).
> 
> the main variation in xfs_iget() is whether we lock the inode 
> read-write, read-only or not at all, correct? (XFS_ILOCK_EXCL, 
> XFS_ILOCK_SHARED and 0)
> 
> That could be cleaned up the following way:

*nod*.  One difficulty is that xfs_iget_core would also need this
treatment (the lock_mode parameter is passed down there), and we
may end up be with quite a few functions and/or duplicated code.
But maybe that can be avoided by arranging that code differently.

> NOTE: since the majority (9 out of 13) of xfs_iget() uses are for the 
> 'no lock' variant, this construction of functions, besides making the 
> code more readable, _further_ reduces overhead, because there is no 
> ilock-flags checking overhead in __xfs_iget() anymore.

Indeed; its fairly minimal overhead though really, the readability
angle appeals to me more.  Its just a fair bit of churn for not a
very tangible gain, so I'm balking at it atm.  Russell is looking
at reworking xfs_iget for other reasons, so maybe he can stew on
all of this and clean it up in the context of his other changes in
there.

Thanks Ingo.

cheers.

-- 
Nathan