xfs: only take the ILOCK in xfs_reclaim_inode()
PATCH 1/1 xfs: only take the ILOCK in xfs_reclaim_inode()
At the end of xfs_reclaim_inode(), the inode is locked in order to we wait for a possible concurrent lookup to complete before the inode is freed. This synchronization step was taking both the ILOCK and the IOLOCK, but the latter was causing lockdep to produce reports of the possibility of deadlock.
It turns out that there's no need to acquire the IOLOCK at this point anyway. It may have been required in some earlier version of the code, but there should be no need to take the IOLOCK in xfs_iget(), so there's no (longer) any need to get it here for synchronization. Add an assertion in xfs_iget() as a reminder of this assumption.
Dave Chinner diagnosed this on IRC, and Christoph Hellwig suggested no longer including the IOLOCK. I just put together the patch.
--- fs/xfs/xfs_iget.c | 9 +++++++++ fs/xfs/xfs_sync.c | 10 ++++------ 2 files changed, 13 insertions(+), 6 deletions(-)
fs/xfs/xfs_iget.c +9 -0
@@ -421,6 +421,15 @@ xfs_iget(xfs_perag_t *pag;xfs_agino_t agino; +/* +* xfs_reclaim_inode() uses the ILOCK to ensure an inode +* doesn't get freed while it's being referenced during a +* radix tree traversal here. It assumes this function +* aqcuires only the ILOCK (and therefore it has no need to +* involve the IOLOCK in this synchronization). +*/ +ASSERT ((lock_flags & (XFS_IOLOCK_EXCL |XFS_IOLOCK_SHARED )) ==0 ); +/* reject inode numbers outside existing AGs */ if (!ino ||XFS_INO_TO_AGNO (mp, ino) >= mp->m_sb.sb_agcount)return EINVAL ;
fs/xfs/xfs_sync.c +4 -6
@@ -918,17 +918,15 @@ reclaim:* can reference the inodes in the cache without taking references. * * We make that OK here by ensuring that we wait until the inode is -* unlocked after the lookup before we go ahead and free it. We get -* both the ilock and the iolock because the code may need to drop the -* ilock one but will still hold the iolock. +* unlocked after the lookup before we go ahead and free it. */ -xfs_ilock (ip,XFS_ILOCK_EXCL |XFS_IOLOCK_EXCL ); +xfs_ilock (ip,XFS_ILOCK_EXCL );xfs_qm_dqdetach (ip); -xfs_iunlock (ip,XFS_ILOCK_EXCL |XFS_IOLOCK_EXCL ); +xfs_iunlock (ip,XFS_ILOCK_EXCL );xfs_inode_free (ip); -return error; +return error; }/*
Signature · 8 lines
1.7.5.4 _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 13 lines · Alex Elder
At the end of
xfs_reclaim_inode(), the inode is locked in order to we wait for a possible concurrent lookup to complete before the inode is freed. This synchronization step was taking both the ILOCK and the IOLOCK, but the latter was causing lockdep to produce reports of the possibility of deadlock.It turns out that there's no need to acquire the IOLOCK at this point anyway. It may have been required in some earlier version of the code, but there should be no need to take the IOLOCK in
xfs_iget(), so there's no (longer) any need to get it here for synchronization. Add an assertion inxfs_iget()as a reminder of this assumption.
Quoted 4 lines
Dave Chinner diagnosed this on IRC, and Christoph Hellwig suggested no longer including the IOLOCK. I just put together the patch.
Signed-off-by Alex Elder <[email protected]>
The code and comments is almost identical to the patch I've been testing over the past day, so consider it
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Looks good,
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 13 lines · Alex Elder
At the end of
xfs_reclaim_inode(), the inode is locked in order to we wait for a possible concurrent lookup to complete before the inode is freed. This synchronization step was taking both the ILOCK and the IOLOCK, but the latter was causing lockdep to produce reports of the possibility of deadlock.It turns out that there's no need to acquire the IOLOCK at this point anyway. It may have been required in some earlier version of the code, but there should be no need to take the IOLOCK in
xfs_iget(), so there's no (longer) any need to get it here for synchronization. Add an assertion inxfs_iget()as a reminder of this assumption.
Quoted 4 lines
Dave Chinner diagnosed this on IRC, and Christoph Hellwig suggested no longer including the IOLOCK. I just put together the patch.
Signed-off-by Alex Elder <[email protected]>
Looks good.
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs