diff options
author | Dave Chinner <dchinner@redhat.com> | 2016-01-04 16:28:25 +1100 |
---|---|---|
committer | Dave Chinner <david@fromorbit.com> | 2016-01-04 16:28:25 +1100 |
commit | a6d7636e8d0fd94fd1937db91d5b06a91fa85dde (patch) | |
tree | 41b326d5e1ee03a7948c692064002d18282d3fe2 /fs/gfs2 | |
parent | 3b0fe47805802216087259b07de691ef47ff6fbc (diff) | |
download | linux-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/gfs2')
0 files changed, 0 insertions, 0 deletions