summaryrefslogtreecommitdiffstats
path: root/fs/xfs/xfs_discard.h
diff options
context:
space:
mode:
authorDave Chinner <dchinner@redhat.com>2016-01-04 16:28:25 +1100
committerDave Chinner <david@fromorbit.com>2016-01-04 16:28:25 +1100
commita6d7636e8d0fd94fd1937db91d5b06a91fa85dde (patch)
tree41b326d5e1ee03a7948c692064002d18282d3fe2 /fs/xfs/xfs_discard.h
parent3b0fe47805802216087259b07de691ef47ff6fbc (diff)
downloadlinux-a6d7636e8d0fd94fd1937db91d5b06a91fa85dde.tar.gz
linux-a6d7636e8d0fd94fd1937db91d5b06a91fa85dde.tar.bz2
linux-a6d7636e8d0fd94fd1937db91d5b06a91fa85dde.zip
xfs: fix recursive splice read locking with DAX
Doing a splice read (generic/249) generates a lockdep splat because we recursively lock the inode iolock in this path: SyS_sendfile64 do_sendfile do_splice_direct splice_direct_to_actor do_splice_to xfs_file_splice_read <<<<<< lock here default_file_splice_read vfs_readv do_readv_writev do_iter_readv_writev xfs_file_read_iter <<<<<< then here The issue here is that for DAX inodes we need to avoid the page cache path and hence simply push it into the normal read path. Unfortunately, we can't tell down at xfs_file_read_iter() whether we are being called from the splice path and hence we cannot avoid the locking at this layer. Hence we simply have to drop the inode locking at the higher splice layer for DAX. Signed-off-by: Dave Chinner <dchinner@redhat.com> Tested-by: Ross Zwisler <ross.zwisler@linux.intel.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
Diffstat (limited to 'fs/xfs/xfs_discard.h')
0 files changed, 0 insertions, 0 deletions