summaryrefslogtreecommitdiff
path: root/crypto/aegis128-core.c
diff options
context:
space:
mode:
authorEric Sandeen <sandeen@sandeen.net>2020-05-02 04:34:25 +0300
committerNamjae Jeon <namjae.jeon@samsung.com>2020-05-18 05:51:40 +0300
commit035779483072ff7854943dc0cbae82c4e0070d15 (patch)
tree87b97cb780e9e9405f12af20dca3c711ea8658e4 /crypto/aegis128-core.c
parentb9bbe6ed63b2b9f2c9ee5cbd0f2c946a2723f4ce (diff)
downloadlinux-035779483072ff7854943dc0cbae82c4e0070d15.tar.xz
exfat: use iter_file_splice_write
Doing copy_file_range() on exfat with a file opened for direct IO leads to an -EFAULT: # xfs_io -f -d -c "truncate 32768" \ -c "copy_range -d 16384 -l 16384 -f 0" /mnt/test/junk copy_range: Bad address and the reason seems to be that we go through: default_file_splice_write splice_from_pipe __splice_from_pipe write_pipe_buf __kernel_write new_sync_write generic_file_write_iter generic_file_direct_write exfat_direct_IO do_blockdev_direct_IO iov_iter_get_pages and land in iterate_all_kinds(), which does "return -EFAULT" for our kvec iter. Setting exfat's splice_write to iter_file_splice_write fixes this and lets fsx (which originally detected the problem) run to success from the xfstests harness. Signed-off-by: Eric Sandeen <sandeen@sandeen.net> Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Diffstat (limited to 'crypto/aegis128-core.c')
0 files changed, 0 insertions, 0 deletions