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@xxxxxxx> Reviewed-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx> Acked-by: David Sterba <dsterba@xxxxxxxx> --- 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 71e9077f8bc1..7188982e2733 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 -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html