[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20210212124354.6.Idc9c3110d708aa0df9d8fe5a6246524dc8469dae@changeid>
Date: Fri, 12 Feb 2021 12:44:05 +0800
From: Nicolas Boichat <drinkcat@...omium.org>
To: "Darrick J . Wong" <djwong@...nel.org>
Cc: Alexander Viro <viro@...iv.linux.org.uk>,
Ian Lance Taylor <iant@...gle.com>,
Luis Lozano <llozano@...omium.org>,
Greg KH <gregkh@...uxfoundation.org>,
Dave Chinner <david@...morbit.com>,
Nicolas Boichat <drinkcat@...omium.org>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH 6/6] vfs: Disallow copy_file_range on generated file systems
copy_file_range (which calls generic_copy_file_checks) uses the
inode file size to adjust the copy count parameter. This breaks
with special filesystems like procfs/sysfs/debugfs/tracefs, where
the file size appears to be zero, but content is actually returned
when a read operation is performed. Other issues would also
happen on partial writes, as the function would attempt to seek
in the input file.
Use the newly introduced FS_GENERATED_CONTENT filesystem flag
to return -EOPNOTSUPP: applications can then retry with a more
usual read/write based file copy (the fallback code is usually
already present to handle older kernels).
Signed-off-by: Nicolas Boichat <drinkcat@...omium.org>
---
fs/read_write.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/read_write.c b/fs/read_write.c
index 0029ff2b0ca8..80322e89fb0a 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -1485,6 +1485,9 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
if (flags != 0)
return -EINVAL;
+ if (file_inode(file_in)->i_sb->s_type->fs_flags & FS_GENERATED_CONTENT)
+ return -EOPNOTSUPP;
+
ret = generic_copy_file_checks(file_in, pos_in, file_out, pos_out, &len,
flags);
if (unlikely(ret))
--
2.30.0.478.g8a0d178c01-goog
Powered by blists - more mailing lists