On Fri, 2024-07-05 at 15:27 +0300, Amir Goldstein wrote:

 	 
External email : Please do not click links or open attachments until
you have verified the sender or the content.
 On Fri, Jul 5, 2024 at 11:17 AM [off-list ref] wrote:

quoted

From: Ed Tsai <redacted>

Filesystems may define their own splice write. Therefore, use file
fops instead of invoking iter_file_splice_write() directly.

This looks sane, but can you share the scenario where you ran into
this?
or did you find this via code audit?

I can think of these cases:
1. overlayfs with fuse (virtiofs) upper
2. fuse passthrough over fuse
3. fuse passthrough over overlayfs
4. fuse passthrough over gfs2 or some out of tree fs

The first two will not cause any harm,
In case #3, according to the comment above ovl_splice_write()
the current code could even deadlock.

So do you have a reproduction?

Thanks,
Amir.

I came across this while checking what's new in the next LTS kernel.

This appears to be taken from overlayfs, and currently, no one has
encountered any issus about this.



On Sun, 2024-07-07 at 21:42 +0100, Matthew Wilcox wrote:

On Fri, Jul 05, 2024 at 04:16:39PM +0800, ed.tsai@mediatek.com wrote:

quoted

+++ b/fs/backing-file.c

@@ -280,13 +280,16 @@ ssize_t backing_file_splice_write(struct

pipe_inode_info *pipe,

quoted

 if (WARN_ON_ONCE(!(out->f_mode & FMODE_BACKING)))
 return -EIO;
 
+if (out->f_op->splice_write)
+return -EINVAL;

Umm ... shouldn't this have been !out->f_op->splice_write?

OMG... This is the wrong version. I will send the correct on later.

quoted

 ret = file_remove_privs(ctx->user_file);
 if (ret)
 return ret;
 
 old_cred = override_creds(ctx->cred);
 file_start_write(out);
-ret = iter_file_splice_write(pipe, out, ppos, len, flags);
+ret = out->f_op->splice_write(pipe, out, ppos, len, flags);
 file_end_write(out);
 revert_creds(old_cred);
 
-- 
2.18.0