xfs
[Top] [All Lists]

[PATCH] xfs: Re-initialise lockdep context for all inodes in reclaim

To: xfs@xxxxxxxxxxx
Subject: [PATCH] xfs: Re-initialise lockdep context for all inodes in reclaim
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 27 May 2010 11:59:06 +1000
From: Dave Chinner <dchinner@xxxxxxxxxx>

We re-initialise the lockdep context for inode iolocks when dropping an inode,
but not when we delete an inode. Now that we can reclaim inodes from a shrinker,
we can get get false lockdep warnings about inode iolock inversions during
reclaim of deleted inodes. Hence we need to re-initialise the iolock in the
delete path as well.

Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
---
 fs/xfs/linux-2.6/xfs_super.c |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/fs/xfs/linux-2.6/xfs_super.c b/fs/xfs/linux-2.6/xfs_super.c
index 8119d1b..ba0e884 100644
--- a/fs/xfs/linux-2.6/xfs_super.c
+++ b/fs/xfs/linux-2.6/xfs_super.c
@@ -911,6 +911,20 @@ xfs_fs_destroy_inode(
 
        XFS_STATS_INC(vn_reclaim);
 
+       /*
+        * The iolock is used by the file system to coordinate reads,
+        * writes, and block truncates.  Up to this point the lock
+        * protected concurrent accesses by users of the inode.  But
+        * from here forward we're doing some final processing of the
+        * inode because we're done with it, and although we reuse the
+        * iolock for protection it is really a distinct lock class
+        * (in the lockdep sense) from before.  To keep lockdep happy
+        * (and basically indicate what we are doing), we explicitly
+        * re-init the iolock here.
+        */
+       ASSERT(!rwsem_is_locked(&ip->i_iolock.mr_lock));
+       mrlock_init(&ip->i_iolock, MRLOCK_BARRIER, "xfsio", ip->i_ino);
+
        /* bad inode, get out here ASAP */
        if (is_bad_inode(inode))
                goto out_reclaim;
-- 
1.5.6.5

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