All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: fsdevel <linux-fsdevel@vger.kernel.org>,
	Namjae Jeon <namjae.jeon@samsung.com>,
	Al Viro <viro@ZenIV.linux.org.uk>
Subject: [PATCH] exfat: use iter_file_splice_write
Date: Fri, 1 May 2020 20:34:25 -0500	[thread overview]
Message-ID: <f7b13155-5f56-1d14-4c26-e1fea8d04a62@sandeen.net> (raw)

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>
---

I know that's not a good changelog; I conferred with viro about whether this
is correct, but I still don't have a great explanation, so feel free to fix up
the changelog to be more informative if the change is otherwise correct...

diff --git a/fs/exfat/file.c b/fs/exfat/file.c
index 4f76764165cf..c9db8eb0cfc3 100644
--- a/fs/exfat/file.c
+++ b/fs/exfat/file.c
@@ -348,12 +348,13 @@ int exfat_setattr(struct dentry *dentry, struct iattr *attr)
 }
 
 const struct file_operations exfat_file_operations = {
-	.llseek      = generic_file_llseek,
-	.read_iter   = generic_file_read_iter,
-	.write_iter  = generic_file_write_iter,
-	.mmap        = generic_file_mmap,
-	.fsync       = generic_file_fsync,
-	.splice_read = generic_file_splice_read,
+	.llseek		= generic_file_llseek,
+	.read_iter	= generic_file_read_iter,
+	.write_iter	= generic_file_write_iter,
+	.mmap		= generic_file_mmap,
+	.fsync		= generic_file_fsync,
+	.splice_read	= generic_file_splice_read,
+	.splice_write	= iter_file_splice_write,
 };
 
 const struct inode_operations exfat_file_inode_operations = {



             reply	other threads:[~2020-05-02  1:34 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-02  1:34 Eric Sandeen [this message]
2020-05-03 14:47 ` [PATCH] exfat: use iter_file_splice_write Namjae Jeon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f7b13155-5f56-1d14-4c26-e1fea8d04a62@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=namjae.jeon@samsung.com \
    --cc=viro@ZenIV.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.