Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2823399pxj; Mon, 17 May 2021 10:34:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzrHWU8COcPO9KGjLi6sgglxy2bB9TiOa2srbKQzXvullMAuNeocLpW/IzMu+uJgh4xq3xs X-Received: by 2002:a6b:ea0e:: with SMTP id m14mr914514ioc.182.1621272894184; Mon, 17 May 2021 10:34:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621272894; cv=none; d=google.com; s=arc-20160816; b=oGT7Kp2qJMKpEiPs38nVePWB8zOwgMEid3jHF+O6JaEAefQJLDPOrm23/O/0F4WSNu OX+q+YHfEl/OX6oKsZ/tmeg2pvueP7xD170ddYFQxEwpfEyITfrUBszM1hKdxXv6Ec36 LcOhEuOUyC/wo67LIJJboglLDpuD9+anaII5dOpSztzSoGW+n46qwbiTytTF+eOmuPXP rwgSYNPYgZ3lBsMa6vRQw1qffMya5qq++4b+vlikcz7dIdyLakyWVaNfd+t6rmLaG4aV Sg5mLMDNT5Gmyfr754D9pkT/6xrLY4SSw/qeiw4eY/jRHehAK4oxOyTPFfC5ohXSehni az+w== 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=z9hqHG++OnRGrZoPPevC6BtmncXfZKk2jqHa9RqkuOc=; b=aYovOTx6U9l+OljxthNHRR+QFbGKdvBz58L3Malc1tpcFD+mJBNNvtsI1FI5zXxQDW 8h3cHQQ9UPD/8OdiBYszLlbkEr6V6orLXzmdR2Pm7CdT7SfN5+16vdMqSYXl68AtSI5V ZnMcPUqlli9q0Fi6xCyRmcGpENXJG6FuAj0tnz2lkmgKuUkW5nX5Faqd72yClJwenaud Ph0WmpFCc5IImDnVUViazPvkhhFznrouuTX8OfYaqgJku5ZxFRq07RF1Vi0A6jHme/ET EmLUfNJyRmcqm0KISpxnKNPfGxzLdfN+mSwLBffI6evghUyaybd5IxbwMqr+pBzZwRLY 2UFQ== 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 d2si17307386ios.97.2021.05.17.10.34.40; Mon, 17 May 2021 10:34:54 -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 S236588AbhEQKzL (ORCPT + 99 others); Mon, 17 May 2021 06:55:11 -0400 Received: from mx2.suse.de ([195.135.220.15]:35202 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236591AbhEQKzI (ORCPT ); Mon, 17 May 2021 06:55:08 -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 96607B039; Mon, 17 May 2021 10:53:50 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id 2F468DAF1B; Mon, 17 May 2021 12:51:18 +0200 (CEST) Date: Mon, 17 May 2021 12:51:18 +0200 From: David Sterba To: Khaled ROMDHANI Cc: clm@fb.com, josef@toxicpanda.com, dsterba@suse.com, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org Subject: Re: [PATCH] fs/btrfs: Fix uninitialized variable Message-ID: <20210517105117.GL7604@twin.jikos.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Khaled ROMDHANI , clm@fb.com, josef@toxicpanda.com, dsterba@suse.com, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org References: <20210501225046.9138-1-khaledromdhani216@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210501225046.9138-1-khaledromdhani216@gmail.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 Sat, May 01, 2021 at 11:50:46PM +0100, Khaled ROMDHANI wrote: > Fix the warning: variable 'zone' is used > uninitialized whenever '?:' condition is true. > > Fix that by preventing the code to reach > the last assertion. If the variable 'mirror' > is invalid, the assertion fails and we return > immediately. > > Reported-by: kernel test robot > Signed-off-by: Khaled ROMDHANI This took several rounds and none of them was close to what I'd consider a proper fix, for something that's not really important. As Dan said, smatch does understand the values passed from the callers and the function is a static inline so the complete information is available. No tricky analysis is required, so why does not coverity see that too? We use assertions to namely catch programmer errors and API misuse, anything that can happen at runtime or depends on input needs proper checks and error handling. But for the super block copies, the constant won't change so all we want is to catch the stupid errors. > --- > fs/btrfs/zoned.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/btrfs/zoned.c b/fs/btrfs/zoned.c > index 8250ab3f0868..23da9d8dc184 100644 > --- a/fs/btrfs/zoned.c > +++ b/fs/btrfs/zoned.c > @@ -145,7 +145,7 @@ static inline u32 sb_zone_number(int shift, int mirror) > case 2: zone = 1ULL << (BTRFS_SB_LOG_SECOND_SHIFT - shift); break; > default: > ASSERT((u32)mirror < 3); > - break; > + return 0; It's been pointed out that this does not apply on the current code but on top of previous versions, so it's not making it easy for me to apply the patch and do maybe some tweaks only. I don't mind merging trivial patches, people can learn the process and few iterations are not a big deal. What I also hope for is to get some understanding of the code being changed and not just silencing some tools' warnings.