xfs: reset the i_iolock lock class in the reclaim path
authorChristoph Hellwig <hch@infradead.org>
Mon, 19 Oct 2009 04:05:26 +0000 (04:05 +0000)
committerAlex Elder <aelder@sgi.com>
Fri, 11 Dec 2009 21:11:20 +0000 (15:11 -0600)
commit033da48fda9d56e28b3fe3ef87ef6fd43290f554
tree0883ff1fd99a9d9bff00c2694e6b66ae12a39bba
parent80641dc66a2d6dfb22af4413227a92b8ab84c7bb
xfs: reset the i_iolock lock class in the reclaim path

The iolock is used for protecting reads, writes and block truncates
against each other.  We have two classes of callers, the first one is
induced by a file operation and requires a reference to the inode be
held and not dropped after the operation is done:

 - xfs_vm_vmap, xfs_vn_fallocate, xfs_read, xfs_write, xfs_splice_read,
   xfs_splice_write and xfs_setattr are all implementations of VFS
   methods that require a live inode
 - xfs_getbmap and xfs_swap_extents are ioctl subcommand for which the
   same is true
 - xfs_truncate_file is only called on quota inodes just returned from
   xfs_iget
 - xfs_sync_inode_data does the lock just after an igrab()
 - xfs_filestream_associate and xfs_filestream_new_ag take the iolock
   on the parent inode of an inode which by VFS rules must be referenced

And we have various calls to truncate blocks past EOF or the whole
file when dropping the last reference to an inode.  Unfortunately
lockdep complains when we do memory allocations that can recurse into
the filesystem in the first class because the second class happens to
take the same lock.  To avoid this re-init the iolock in the beginning
of xfs_fs_clear_inode to get a new lock class.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Alex Elder <aelder@sgi.com>
Signed-off-by: Alex Elder <aelder@sgi.com>
fs/xfs/linux-2.6/xfs_super.c
fs/xfs/xfs_iget.c