summaryrefslogtreecommitdiff
path: root/fs/xfs/xfs_buf.c
diff options
context:
space:
mode:
authorDave Chinner <dchinner@redhat.com>2018-06-07 07:36:08 -0700
committerDarrick J. Wong <darrick.wong@oracle.com>2018-06-08 10:07:51 -0700
commitef215e394eeb960ea0e8a0fd37ba2fa30260e05b (patch)
treebd45ee87b4f1def40e02b62e96ce4099c9d977c8 /fs/xfs/xfs_buf.c
parent4bb8b65a04273c5acd6d1e08e08b757b4e6f4913 (diff)
xfs: setup VFS i_rwsem lockdep state correctly
When lockdep is enabled, it changes the type of the inode i_rwsem semaphore before unlocking a newly instantiated inode. THere is the possibility that there is already a waiter on that inode lock by the time we unlock the new inode, so having lockdep re-initialise the lock is a vector for trouble. Avoid this whole situation by setting up the i_rwsem lockdep class at the same time we set up the XFS inode i_ilock classes and so the VFS doesn't have to change the lock class itself when it is potentially unsafe. This change is necessary because the equivalent fixes to the VFS code made in commit 1e2e547a93a0 ("do d_instantiate/unlock_new_inode combinations safely") are not relevant to XFS as it has it's own internal inode cache lookup and instantiation routines. Signed-Off-By: Dave Chinner <dchinner@redhat.com> Reviewed-by: Allison Henderson <allison.henderson@oracle.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Diffstat (limited to 'fs/xfs/xfs_buf.c')
0 files changed, 0 insertions, 0 deletions