On Tue, Jul 14, 2020 at 06:05:09AM -0700, [email protected] wrote:
> From: Tom Rix <[email protected]>
> 
> clang static analysis flags this error
> 
> inode.c:1083:5: warning: Argument to kfree() is the address of the
>   local variable 'unf_single', which is not memory allocated by
>   malloc() [unix.Malloc]
>                                 kfree(un);
>                                 ^~~~~~~~~
> Assignment of 'un'
> 
>       /*
>        * We use this in case we need to allocate
>        * only one block which is a fastpath
>        */
>       unp_t unf_single = 0;
> 
>       ...
> 
>       if (blocks_needed == 1) {
>               un = &unf_single;
>       } else {
>               un = kcalloc(min(blocks_needed, max_to_insert),
>                            UNFM_P_SIZE, GFP_NOFS);
>               if (!un) {
>                       un = &unf_single;
>                       blocks_needed = 1;
>                       max_to_insert = 0;
>               }
>       }
> 
> The logic to free 'un'
> 
>       if (blocks_needed != 1)
>               kfree(un);
> 
> Because the kcalloc failure falls back to using unf_single,
> the if-check for the free is wrong.

I think you mean "Because clang's static analysis is limited, it
warns incorrectly about this".  There's no path to get to the
kfree with blocks_needed != 1 and un being equal to &unf_single.

> So improve the check.
> 
> Signed-off-by: Tom Rix <[email protected]>
> ---
>  fs/reiserfs/inode.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/reiserfs/inode.c b/fs/reiserfs/inode.c
> index 1509775da040..4d62148e43e6 100644
> --- a/fs/reiserfs/inode.c
> +++ b/fs/reiserfs/inode.c
> @@ -1079,7 +1079,7 @@ int reiserfs_get_block(struct inode *inode, sector_t 
> block,
>                                                    UNFM_P_SIZE *
>                                                    blocks_needed);
>  
> -                     if (blocks_needed != 1)
> +                     if (un != &unf_single)
>                               kfree(un);

I don't actually object to this patch, but your analysis of clang's
analysis is wrong.

Reply via email to