| Message ID | 20180414061658.3774-1-zev@bewilderbeest.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sat, Apr 14, 2018 at 01:16:58AM -0500, Zev Weiss wrote: > It's a fairly inconsequential bug, since fdput() won't actually try to > fput() the file due to fd.flags (and thus FDPUT_FPUT) being zero in > the failure case, but most other vfs code takes steps to avoid this. Applied.
diff --git a/fs/read_write.c b/fs/read_write.c index c4eabbfc90df..e83bd9744b5d 100644 --- a/fs/read_write.c +++ b/fs/read_write.c @@ -2023,7 +2023,7 @@ int vfs_dedupe_file_range(struct file *file, struct file_dedupe_range *same) ret = mnt_want_write_file(dst_file); if (ret) { info->status = ret; - goto next_loop; + goto next_fdput; } dst_off = info->dest_offset; @@ -2058,9 +2058,9 @@ int vfs_dedupe_file_range(struct file *file, struct file_dedupe_range *same) next_file: mnt_drop_write_file(dst_file); -next_loop: +next_fdput: fdput(dst_fd); - +next_loop: if (fatal_signal_pending(current)) goto out; }
It's a fairly inconsequential bug, since fdput() won't actually try to fput() the file due to fd.flags (and thus FDPUT_FPUT) being zero in the failure case, but most other vfs code takes steps to avoid this. Signed-off-by: Zev Weiss <zev@bewilderbeest.net> --- fs/read_write.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)