Re: [PATCH] btfrs: initialize return of btrfs_extent_same

[David Sterba]

On Sun, Jul 05, 2020 at 05:48:17PM +0300, Nikolay Borisov wrote:
> On 5.07.20 Ð. 17:20 Ñ., trix@xxxxxxxxxx wrote:
> > From: Tom Rix <trix@xxxxxxxxxx>
> > 
> > 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 <trix@xxxxxxxxxx>
> 
> 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.