aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/filesystems
diff options
context:
space:
mode:
authorDarrick J. Wong <darrick.wong@oracle.com>2018-10-29 19:41:49 -0400
committerDave Chinner <david@fromorbit.com>2018-10-29 19:41:49 -0400
commit42ec3d4c02187a18e27ff94b409ec27234bf2ffd (patch)
treec9db04db8187c370718a43e6067af0e5aa944500 /Documentation/filesystems
parent8dde90bca6fca3736ea20109654bcf6dcf2ecf1d (diff)
vfs: make remap_file_range functions take and return bytes completed
Change the remap_file_range functions to take a number of bytes to operate upon and return the number of bytes they operated on. This is a requirement for allowing fs implementations to return short clone/dedupe results to the user, which will enable us to obey resource limits in a graceful manner. A subsequent patch will enable copy_file_range to signal to the ->clone_file_range implementation that it can handle a short length, which will be returned in the function's return value. For now the short return is not implemented anywhere so the behavior won't change -- either copy_file_range manages to clone the entire range or it tries an alternative. Neither clone ioctl can take advantage of this, alas. Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
Diffstat (limited to 'Documentation/filesystems')
-rw-r--r--Documentation/filesystems/vfs.txt10
1 files changed, 5 insertions, 5 deletions
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt
index 6f5babfee27b..1bd2919deaca 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -883,9 +883,9 @@ struct file_operations {
883 unsigned (*mmap_capabilities)(struct file *); 883 unsigned (*mmap_capabilities)(struct file *);
884#endif 884#endif
885 ssize_t (*copy_file_range)(struct file *, loff_t, struct file *, loff_t, size_t, unsigned int); 885 ssize_t (*copy_file_range)(struct file *, loff_t, struct file *, loff_t, size_t, unsigned int);
886 int (*remap_file_range)(struct file *file_in, loff_t pos_in, 886 loff_t (*remap_file_range)(struct file *file_in, loff_t pos_in,
887 struct file *file_out, loff_t pos_out, 887 struct file *file_out, loff_t pos_out,
888 u64 len, unsigned int remap_flags); 888 loff_t len, unsigned int remap_flags);
889 int (*fadvise)(struct file *, loff_t, loff_t, int); 889 int (*fadvise)(struct file *, loff_t, loff_t, int);
890}; 890};
891 891
@@ -966,8 +966,8 @@ otherwise noted.
966 implementation should remap len bytes at pos_in of the source file into 966 implementation should remap len bytes at pos_in of the source file into
967 the dest file at pos_out. Implementations must handle callers passing 967 the dest file at pos_out. Implementations must handle callers passing
968 in len == 0; this means "remap to the end of the source file". The 968 in len == 0; this means "remap to the end of the source file". The
969 return value should be zero if all bytes were remapped, or the usual 969 return value should the number of bytes remapped, or the usual
970 negative error code if the remapping did not succeed completely. 970 negative error code if errors occurred before any bytes were remapped.
971 The remap_flags parameter accepts REMAP_FILE_* flags. If 971 The remap_flags parameter accepts REMAP_FILE_* flags. If
972 REMAP_FILE_DEDUP is set then the implementation must only remap if the 972 REMAP_FILE_DEDUP is set then the implementation must only remap if the
973 requested file ranges have identical contents. 973 requested file ranges have identical contents.