From: David Sterba <dsterba@suse.cz>
To: Khaled ROMDHANI <khaledromdhani216@gmail.com>
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
Date: Mon, 17 May 2021 12:51:18 +0200 [thread overview]
Message-ID: <20210517105117.GL7604@twin.jikos.cz> (raw)
In-Reply-To: <20210501225046.9138-1-khaledromdhani216@gmail.com>
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 <lkp@intel.com>
> Signed-off-by: Khaled ROMDHANI <khaledromdhani216@gmail.com>
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.
prev parent reply other threads:[~2021-05-17 10:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-01 22:50 [PATCH] fs/btrfs: Fix uninitialized variable Khaled ROMDHANI
2021-05-02 10:17 ` Christophe JAILLET
2021-05-03 8:49 ` Khaled Romdhani
2021-05-03 7:23 ` Dan Carpenter
2021-05-03 10:13 ` Khaled Romdhani
2021-05-03 11:55 ` Dan Carpenter
2021-05-03 11:58 ` Colin Ian King
2021-05-17 10:51 ` David Sterba [this message]
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=20210517105117.GL7604@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=josef@toxicpanda.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=khaledromdhani216@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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