[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20191002140138.eug7xvwhlsn5qnby@MacBook-Pro-91.local>
Date: Wed, 2 Oct 2019 10:01:39 -0400
From: Josef Bacik <josef@...icpanda.com>
To: Colin Ian King <colin.king@...onical.com>
Cc: Chris Mason <clm@...com>, Josef Bacik <josef@...icpanda.com>,
David Sterba <dsterba@...e.com>, linux-btrfs@...r.kernel.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Btrfs: add a extent ref verify tool (static analysis bug report)
On Wed, Oct 02, 2019 at 02:50:51PM +0100, Colin Ian King wrote:
> Hi,
>
> Static analysis on linux-next with Coverity has picked up a potential
> issue in file fs/btrfs/ref-verify.c, function process_leaf() in the
> following commit:
>
> commit fd708b81d972a0714b02a60eb4792fdbf15868c4
> Author: Josef Bacik <josef@...icpanda.com>
> Date: Fri Sep 29 15:43:50 2017 -0400
>
> Btrfs: add a extent ref verify tool
>
> The potential issue is when on the unlikely event when all the items
> contain unknown key.types and so ret is not assigned a value. Since ret
> is not initialized then a garbage value is returned by this function in
> this unlikely scenario.
>
> In the previous function process_extent_item any unknown key types are
> flagged up as an error and -EINVAL is returned. I'm unsure if this kind
> of error handling should also be applied to function process_leaf with
> invalid key types too.
>
Thanks I'll fix this up. You can run into block group item key types and we
don't care about those, so we just need ret = 0; Thanks,
Josef
Powered by blists - more mailing lists