On Wed, Jul 13, 2022 at 08:51:44PM +0200, Ansgar Lößer wrote: > When using the FIDEDUPRANGE ioctl, in case of success the requested size > is returned. In some cases this might not be the actual amount of bytes > deduplicated. > > This change modifies vfs_dedupe_file_range() to report the actual amount > of bytes deduplicated, instead of the requested amount. > > Link: https://lore.kernel.org/linux-fsdevel/5548ef63-62f9-4f46-5793-03165ceccacc@xxxxxxxxxxxxxxx/ > > Reported-by: Ansgar Lößer (ansgar.loesser@xxxxxxxxxxxxxxxxxxx) > Reported-by: Max Schlecht (max.schlecht@xxxxxxxxxxxxxxxxxxxxxxx) > Reported-by: Björn Scheuermann (scheuermann@xxxxxxxxxxxxxxxxxxx) > Signed-off-by: Ansgar Lößer <ansgar.loesser@xxxxxxxxxxxxxxxxxxx> > --- > > > Mind sending it with a sign-off and a short commit message? > > > > Linus > Sure, thank you! > > This is my first commit, so I hope it is ok like this. > > > fs/remap_range.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/remap_range.c b/fs/remap_range.c > index e112b5424cdb..072c2c48aeed 100644 > --- a/fs/remap_range.c > +++ b/fs/remap_range.c > @@ -546,7 +546,7 @@ int vfs_dedupe_file_range(struct file *file, struct > file_dedupe_range *same) > else if (deduped < 0) > info->status = deduped; > else > - info->bytes_deduped = len; > + info->bytes_deduped = deduped; > > next_fdput: > fdput(dst_fd); That's a potential change of API behaviour that userspace may barf on as this now can return "success/0 bytes" instead of "success/len". e.g. If userspace is looping over a file based on the returned info->bytes_deduped value, can this change cause them to behave differently? e.g. get stuck in an endless loop on the EOF block always returning SAME/0 instead of DIFFER? Also, doesn't this just paper over the bug in vfs_dedupe_file_range_compare() where it returns is_same = true when the length to compare is zero as will happen when comparing differing EOF blocks now when it should be returning -EBADE? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
