[bug report] btrfs: clean BTRFS_I usage in btrfs_destroy_inode

[bug report] btrfs: clean BTRFS_I usage in btrfs_destroy_inode

[Dan Carpenter]

Hello Nikolay Borisov,

This is a semi-automatic email about new static checker warnings.

The patch ab46388723da: "btrfs: clean BTRFS_I usage in
btrfs_destroy_inode" from Sep 18, 2020, leads to the following Smatch
complaint:

    fs/btrfs/inode.c:8668 btrfs_destroy_inode()
    warn: variable dereferenced before check 'root' (see line 8651)

fs/btrfs/inode.c
  8650		struct btrfs_root *root = inode->root;
  8651		struct btrfs_fs_info *fs_info = root->fs_info;
                                                ^^^^^^^^^^^^^
New dereference

  8652	
  8653		WARN_ON(!hlist_empty(&vfs_inode->i_dentry));
  8654		WARN_ON(vfs_inode->i_data.nrpages);
  8655		WARN_ON(inode->block_rsv.reserved);
  8656		WARN_ON(inode->block_rsv.size);
  8657		WARN_ON(inode->outstanding_extents);
  8658		WARN_ON(inode->delalloc_bytes);
  8659		WARN_ON(inode->new_delalloc_bytes);
  8660		WARN_ON(inode->csum_bytes);
  8661		WARN_ON(inode->defrag_bytes);
  8662	
  8663		/*
  8664		 * This can happen where we create an inode, but somebody else also
  8665		 * created the same inode and we need to destroy the one we already
  8666		 * created.
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
But "root" can be NULL.

  8667		 */
  8668		if (!root)
                    ^^^^^
  8669			return;
  8670	

regards,
dan carpenter

Re: [bug report] btrfs: clean BTRFS_I usage in btrfs_destroy_inode

[David Sterba]

On Tue, Sep 22, 2020 at 02:01:18PM +0300, Dan Carpenter wrote:
> Hello Nikolay Borisov,
> 
> This is a semi-automatic email about new static checker warnings.
> 
> The patch ab46388723da: "btrfs: clean BTRFS_I usage in
> btrfs_destroy_inode" from Sep 18, 2020, leads to the following Smatch
> complaint:

Thanks for the report.

There's a fix
https://lore.kernel.org/linux-btrfs/20200921191243.27833-1-a.dewar@sussex.ac.uk/

but now that I see you actually point to the right patch that caused it,
which is still in the pending branch so I can fold the fixup there.