| Message ID | 20180518215727.26418-3-mfasheh@suse.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, May 18, 2018 at 02:57:27PM -0700, Mark Fasheh wrote: > Right now we return EINVAL if a process does not have permission to dedupe a > file. This was an oversight on my part. EPERM gives a true description of > the nature of our error, and EINVAL is already used for the case that the > filesystem does not support dedupe. > > Signed-off-by: Mark Fasheh <mfasheh@suse.de> Looks ok what with all the okays after I squawked last time, Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> --D > --- > fs/read_write.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/read_write.c b/fs/read_write.c > index cbea4ce58ad1..2238928ca819 100644 > --- a/fs/read_write.c > +++ b/fs/read_write.c > @@ -2050,7 +2050,7 @@ int vfs_dedupe_file_range(struct file *file, struct file_dedupe_range *same) > if (info->reserved) { > info->status = -EINVAL; > } else if (!allow_file_dedupe(dst_file)) { > - info->status = -EINVAL; > + info->status = -EPERM; > } else if (file->f_path.mnt != dst_file->f_path.mnt) { > info->status = -EXDEV; > } else if (S_ISDIR(dst->i_mode)) { > -- > 2.15.1 >
On Fri, May 18, 2018 at 03:04:13PM -0700, Darrick J. Wong wrote: > On Fri, May 18, 2018 at 02:57:27PM -0700, Mark Fasheh wrote: > > Right now we return EINVAL if a process does not have permission to dedupe a > > file. This was an oversight on my part. EPERM gives a true description of > > the nature of our error, and EINVAL is already used for the case that the > > filesystem does not support dedupe. > > > > Signed-off-by: Mark Fasheh <mfasheh@suse.de> > > Looks ok what with all the okays after I squawked last time, > Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Awesome, I'll put that in the patch. Thanks Darrick. --Mark
On Fri, May 18, 2018 at 02:57:27PM -0700, Mark Fasheh wrote: > Right now we return EINVAL if a process does not have permission to dedupe a > file. This was an oversight on my part. EPERM gives a true description of > the nature of our error, and EINVAL is already used for the case that the > filesystem does not support dedupe. > > Signed-off-by: Mark Fasheh <mfasheh@suse.de> I gave my ack for v1, no change so Acked-by: David Sterba <dsterba@suse.com>
diff --git a/fs/read_write.c b/fs/read_write.c index cbea4ce58ad1..2238928ca819 100644 --- a/fs/read_write.c +++ b/fs/read_write.c @@ -2050,7 +2050,7 @@ int vfs_dedupe_file_range(struct file *file, struct file_dedupe_range *same) if (info->reserved) { info->status = -EINVAL; } else if (!allow_file_dedupe(dst_file)) { - info->status = -EINVAL; + info->status = -EPERM; } else if (file->f_path.mnt != dst_file->f_path.mnt) { info->status = -EXDEV; } else if (S_ISDIR(dst->i_mode)) {
Right now we return EINVAL if a process does not have permission to dedupe a file. This was an oversight on my part. EPERM gives a true description of the nature of our error, and EINVAL is already used for the case that the filesystem does not support dedupe. Signed-off-by: Mark Fasheh <mfasheh@suse.de> --- fs/read_write.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)