On Mon, Jan 28, 2013 at 09:04:30AM -0500, Carlos Maiolino wrote: > There is no reason to ASSERT(xfs_isilocked(ip, XFS_ILOCK_EXCL)); twice, so, > remove one of these ASSERT calls Second assert is for the IOLOCK, not the ILOCK.... > Signed-off-by: Carlos Maiolino <cmaiolino@xxxxxxxxxx> > --- > fs/xfs/xfs_inode.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c > index 66282dc..25226ea 100644 > --- a/fs/xfs/xfs_inode.c > +++ b/fs/xfs/xfs_inode.c > @@ -1396,8 +1396,7 @@ xfs_itruncate_extents( > int done = 0; > > ASSERT(xfs_isilocked(ip, XFS_ILOCK_EXCL)); > - ASSERT(!atomic_read(&VFS_I(ip)->i_count) || > - xfs_isilocked(ip, XFS_IOLOCK_EXCL)); > + ASSERT(!atomic_read(&VFS_I(ip)->i_count)); The code is correct. The ASSERT is testing the locking constraints on the XFS_IOLOCK_EXCL. That is, if xfs_itruncate_extents() is called in the VFS inode reclaim path (i.e. via xfs_inactive()), the IO lock is not used (throws lockdep warnings). Hence the ASSERT is checking that if we hold an inode reference, we are also holding the IO lock. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
