On Sun, Jul 05, 2020 at 05:48:17PM +0300, Nikolay Borisov wrote: > On 5.07.20 г. 17:20 ч., t...@redhat.com wrote: > > From: Tom Rix <t...@redhat.com> > > > > clang static analysis flags a garbage return > > > > fs/btrfs/reflink.c:611:2: warning: Undefined or garbage value returned to > > caller [core.uninitialized.UndefReturn] > > return ret; > > ^~~~~~~~~~ > > ret will not be set when olen is 0 > > When olen is 0, this function does no work. > > > > So initialize ret to 0 > > > > Signed-off-by: Tom Rix <t...@redhat.com> > > Patch itself is good however, the bug cannot currently be triggered, due > to the following code in the sole caller (btrfs_remap_file_range): > > > > 15 if (ret < 0 || len == 0) > 14 goto out_unlock; > 13 > 12 if (remap_flags & REMAP_FILE_DEDUP) > 11 ret = btrfs_extent_same(src_inode, off, len, dst_inode, > destoff); > 10 else > 9 ret = btrfs_clone_files(dst_file, src_file, off, > len, destoff); > > i.e len is guaranteed to be non-zero
Yeah, for that reason I don't think we need to set the value inside btrfs_extent_same because the caller(s) do the sanity checks. There are VFS-level checks of the length wrt zero, eg. it won't even call to copy_file_range from vfs_copy_file_range. The user supplied length = 0 is interpreted as 'until the end of file' and is properly reclaculated in generic_remap_file_range_prep. This looks like clang checker is not able to follow the values accross function calls, even if the functions are static.
