linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: jing yangyang <cgel.zte@gmail.com>, Chris Mason <clm@fb.com>
Cc: Josef Bacik <josef@toxicpanda.com>,
	David Sterba <dsterba@suse.com>,
	linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org,
	jing yangyang <jing.yangyang@zte.com.cn>,
	Zeal Robot <zealci@zte.com.cn>
Subject: Re: [PATCH linux-next] fs: btrfs: fix returnvar.cocci warnings
Date: Fri, 20 Aug 2021 11:16:24 +0800	[thread overview]
Message-ID: <900f28f9-6efe-48a7-246f-797a9aa48c07@gmx.com> (raw)
In-Reply-To: <20210820023229.11369-1-jing.yangyang@zte.com.cn>



On 2021/8/20 上午10:32, jing yangyang wrote:
> Remove unneeded variables when "0" can be returned.
>
> Generated by: scripts/coccinelle/misc/returnvar.cocci
>
> Reported-by: Zeal Robot <zealci@zte.com.cn>
> Signed-off-by: jing yangyang <jing.yangyang@zte.com.cn>
> ---
>   fs/btrfs/extent_map.c | 3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/fs/btrfs/extent_map.c b/fs/btrfs/extent_map.c
> index 4a8e02f..58860d7 100644
> --- a/fs/btrfs/extent_map.c
> +++ b/fs/btrfs/extent_map.c
> @@ -296,7 +296,6 @@ static void try_merge_map(struct extent_map_tree *tree, struct extent_map *em)
>   int unpin_extent_cache(struct extent_map_tree *tree, u64 start, u64 len,
>   		       u64 gen)
>   {
> -	int ret = 0;
>   	struct extent_map *em;
>   	bool prealloc = false;
>

Please just check the lines below:

	em = lookup_extent_mapping(tree, start, len);

	WARN_ON(!em || em->start != start);

	if (!em)
		goto out;

This looks more like a missing error handling.

Thus the proper way to fix it is not just simply remove the "int ret =
0;" line (which compiler is more than able to optimize it out), but
properly add the error handling, and modify the only caller to catch
such error properly.

Some diff like the below would be more meaningful:

diff --git a/fs/btrfs/extent_map.c b/fs/btrfs/extent_map.c
index 4a8e02f7b6c7..9182d747a50e 100644
--- a/fs/btrfs/extent_map.c
+++ b/fs/btrfs/extent_map.c
@@ -303,10 +303,11 @@ int unpin_extent_cache(struct extent_map_tree
*tree, u64 start, u64 len,
  	write_lock(&tree->lock);
  	em = lookup_extent_mapping(tree, start, len);

-	WARN_ON(!em || em->start != start);
-
-	if (!em)
+	if (!em || em->start != start) {
+		WARN(1, KERN_WARNING "unexpected extent mapping\n");
+		ret = -EUCLEAN;
  		goto out;
+	}

  	em->generation = gen;
  	clear_bit(EXTENT_FLAG_PINNED, &em->flags);
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 2aa9646bce56..313b0a314c0b 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -2989,6 +2989,7 @@ static int btrfs_finish_ordered_io(struct
btrfs_ordered_extent *ordered_extent)
  	u64 start, end;
  	int compress_type = 0;
  	int ret = 0;
+	int ret2;
  	u64 logical_len = ordered_extent->num_bytes;
  	bool freespace_inode;
  	bool truncated = false;
@@ -3076,8 +3077,11 @@ static int btrfs_finish_ordered_io(struct
btrfs_ordered_extent *ordered_extent)
  						ordered_extent->disk_num_bytes);
  		}
  	}
-	unpin_extent_cache(&inode->extent_tree, ordered_extent->file_offset,
+	ret2 = unpin_extent_cache(&inode->extent_tree,
ordered_extent->file_offset,
  			   ordered_extent->num_bytes, trans->transid);
+	if (ret2 < 0 && !ret)
+		ret = ret2;
+
  	if (ret < 0) {
  		btrfs_abort_transaction(trans, ret);
  		goto out;


Thanks,
Qu
> @@ -328,7 +327,7 @@ int unpin_extent_cache(struct extent_map_tree *tree, u64 start, u64 len,
>   	free_extent_map(em);
>   out:
>   	write_unlock(&tree->lock);
> -	return ret;
> +	return 0;
>
>   }
>
>

  reply	other threads:[~2021-08-20  3:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-20  2:32 [PATCH linux-next] fs: btrfs: fix returnvar.cocci warnings jing yangyang
2021-08-20  3:16 ` Qu Wenruo [this message]
2021-08-20 10:40 ` David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=900f28f9-6efe-48a7-246f-797a9aa48c07@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=cgel.zte@gmail.com \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=jing.yangyang@zte.com.cn \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zealci@zte.com.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).