Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp1376528pxy; Thu, 29 Apr 2021 06:00:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwGnoRU52p6GZVbDV0st/VTtofYx+qIi3bhojbj20Ewkxy8QXxPINZn4k01g8aOvWS6gUgi X-Received: by 2002:a05:6402:17ca:: with SMTP id s10mr13466466edy.198.1619701205620; Thu, 29 Apr 2021 06:00:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619701205; cv=none; d=google.com; s=arc-20160816; b=Q+b7fPqgoe5qMeMee8tTSx3BeY5Qnx6o65LGn4sfT5y44Dxo9BhRJwCsxCe+xo3mvR 9Ziehr9Gq8qa1wMveDAHqe4TChesLR4A6qmdkh+RCeH/yBma3qPYmD2ecl7I+KNEemNh THn/3u3X+XQIWhinmgN+0HzrT41Q/d59K9p75qd8qCCe6mq/Cg+08t3pXV8rP4oVuv/u UHNRpvaq/755SIiQ0dFbhaTjq8IZnL9CJ99nqffbdA4ZwdYQsHPY5uRAv9UcO+UFKEAC UDc1VkKFPvtxq4F/UKjmg3sRW5AMayMvVXyeWHMp/J54/lQAFpNdxF/p1dJ7ERz5kWWq gYiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:mail-followup-to:reply-to:message-id :subject:cc:to:from:date; bh=lQdK3YSTDaQbepnUWii01XlBqTEJR/hHRN9PFev2WoU=; b=OW4MwQi8+qB7fMHOXPZaW8OfpHDp9XGm7VnHHbxowEBmSkcirZ1g8Z0+mC1Bn/rx8N csvoAmxRHqwOpw+J0epGZH+Ax1PmUbU+dQae21GIqZUvRXprLY6oxK9sD+iUhhpq/ulT NJtCFWwT6PcCXZq1IXkERr3eG2fEwxLeR3iXOmy/Cp1RUGw5YQzY8BOzvPQiZqqiFmQ2 WgVSM1EUeR9Lz0Czw8utT/4lmVpYdbIHDa3B0fnLmS1+4MwCJ57dDi8YG+c1CY/S8wCD NoYf6KVmf5kiHKl4U47ig7dqU6mxrjGJNhbT8gxyZUtiE91M5fIFO5MQM8EmyzQegzuF aF/w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w9si2696835edq.453.2021.04.29.05.59.23; Thu, 29 Apr 2021 06:00:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237279AbhD2M6g (ORCPT + 99 others); Thu, 29 Apr 2021 08:58:36 -0400 Received: from mx2.suse.de ([195.135.220.15]:41564 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233701AbhD2M6f (ORCPT ); Thu, 29 Apr 2021 08:58:35 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 10EEDB019; Thu, 29 Apr 2021 12:57:48 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id C93AFDA783; Thu, 29 Apr 2021 14:55:24 +0200 (CEST) Date: Thu, 29 Apr 2021 14:55:24 +0200 From: David Sterba To: Jiapeng Chong Cc: clm@fb.com, josef@toxicpanda.com, dsterba@suse.com, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] btrfs: Remove redundant assignment to ret Message-ID: <20210429125524.GU7604@twin.jikos.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Jiapeng Chong , clm@fb.com, josef@toxicpanda.com, dsterba@suse.com, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org References: <1619691320-81639-1-git-send-email-jiapeng.chong@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1619691320-81639-1-git-send-email-jiapeng.chong@linux.alibaba.com> User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 29, 2021 at 06:15:20PM +0800, Jiapeng Chong wrote: > Variable ret is set to zero but this value is never read as it > is overwritten or not used later on, hence it is a redundant > assignment and can be removed. > > Cleans up the following clang-analyzer warning: I've looked at clang analyzer warnings in the past and the dead stores were ones of the least useful, namely because of the return value assignments. > fs/btrfs/volumes.c:8019:4: warning: Value stored to 'ret' is never read > [clang-analyzer-deadcode.DeadStores]. > > fs/btrfs/volumes.c:4757:4: warning: Value stored to 'ret' is never read > [clang-analyzer-deadcode.DeadStores]. > > fs/btrfs/volumes.c:7951:4: warning: Value stored to 'ret' is never read > [clang-analyzer-deadcode.DeadStores]. > > Reported-by: Abaci Robot > Signed-off-by: Jiapeng Chong > --- > fs/btrfs/volumes.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c > index 9a1ead0..30504fa 100644 > --- a/fs/btrfs/volumes.c > +++ b/fs/btrfs/volumes.c > @@ -4754,7 +4754,6 @@ int btrfs_shrink_device(struct btrfs_device *device, u64 new_size) > mutex_unlock(&fs_info->reclaim_bgs_lock); > if (ret < 0) > goto done; > - ret = 0; > btrfs_release_path(path); > break; So this is a code pattern where 'ret' is used for some local function call but we want to make sure it does not go outside of the block as a non-zero value, potentially being returned from the whole function. No harm done if the value is not used later. > } > @@ -7939,7 +7938,7 @@ int btrfs_verify_dev_extents(struct btrfs_fs_info *fs_info) > struct btrfs_key key; > u64 prev_devid = 0; > u64 prev_dev_ext_end = 0; > - int ret = 0; > + int ret; Similar here, initializing ret to zero does no harm. We've had compiler warnings about unitialized ret when some error path was jumping around it. > > /* > * We don't have a dev_root because we mounted with ignorebadroots and > @@ -8016,7 +8015,6 @@ int btrfs_verify_dev_extents(struct btrfs_fs_info *fs_info) > if (ret < 0) > goto out; > if (ret > 0) { > - ret = 0; > break; > } Same pattern as in the first case.