Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220220144606.5695-1-jrdr.linux@gmail.com> <0a2e57ad-2973-ea01-ceda-3262cde1f5aa@gmx.com>
 <CAFqt6zZsv+bMwbdqrcOMCZE08O_q7DGa0ejVAbokLybsSch5fw@mail.gmail.com>
 <a1d126df-a5ee-d47d-bfaa-95b3b221e41a@suse.com> <b2536c4b-bf0f-a2ff-58cf-ef7d17acaf48@intel.com>
In-Reply-To: <b2536c4b-bf0f-a2ff-58cf-ef7d17acaf48@intel.com>
From:   Souptick Joarder <jrdr.linux@gmail.com>
Date:   Fri, 25 Feb 2022 10:46:43 +0530
Message-ID: <CAFqt6zbCootaOTU3hGXZ0cBcMHoiNtXynzzG8oGw8R6fO4muhg@mail.gmail.com>
Subject: Re: [PATCH] btrfs: Initialize ret to 0 in scrub_simple_mirror()
To:     Yujie Liu <yujie.liu@intel.com>
Cc:     Qu Wenruo <wqu@suse.com>, Chris Mason <clm@fb.com>,
        Josef Bacik <josef@toxicpanda.com>, dsterba@suse.com,
        nathan@kernel.org, Nick Desaulniers <ndesaulniers@google.com>,
        linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org,
        llvm@lists.linux.dev, kernel test robot <lkp@intel.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Feb 24, 2022 at 3:18 PM Yujie Liu <yujie.liu@intel.com> wrote:
>
> Hi,
>
> Sorry for the noise of this false alert.
>
> For clang analyzer reports, usually we do internal check firstly. We'll send out the
> report only when we think that it is highly possible to be a true alert.
>
> We scanned our report history and found this report was produced on 1/26, but it was
> still in the internal check domain and was not likely to be sent to Qu or mailing lists,
> so we are kind of confusing about this consequence.
>
> Souptick, could you help to provide the original report by link or attachment?

https://marc.info/?l=linux-mm&m=164487037605771&w=2

> Then we can do some check to figure out whether we have any flaw in our process.
>
> Thanks,
> Yujie
>
> On 2/22/2022 16:04, Qu Wenruo wrote:
> >
> >
> > On 2022/2/22 15:50, Souptick Joarder wrote:
> >> On Mon, Feb 21, 2022 at 5:46 AM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
> >>>
> >>>
> >>>
> >>> On 2022/2/20 22:46, Souptick Joarder wrote:
> >>>> From: "Souptick Joarder (HPE)" <jrdr.linux@gmail.com>
> >>>>
> >>>> Kernel test robot reported below warning ->
> >>>> fs/btrfs/scrub.c:3439:2: warning: Undefined or garbage value
> >>>> returned to caller [clang-analyzer-core.uninitialized.UndefReturn]
> >>>>
> >>>> Initialize ret to 0.
> >>>>
> >>>> Reported-by: kernel test robot <lkp@intel.com>
> >>>> Signed-off-by: Souptick Joarder (HPE) <jrdr.linux@gmail.com>
> >>>
> >>> Although the patch is not yet merged, but I have to say, it's a false alert.
> >>
> >> Yes, I agree it is a false positive but this patch will at least keep
> >> kernel test robot happy :)
> >
> > I'd say we should enhance the compiler to fix the false alert.
> >
> > Thus adding LLVM list here is correct.
> >
> >
> > To me, the root problem is that, we lack the hint to allow clang to know that, @logical_length passed in would not cause u64 overflow.
> >
> > Unfortunately the sanity check to prevent overflow is hidden far away inside tree-checker.c.
> >
> > Maybe some ASSERT() for overflow check would help LLVM to know that?
> >
> > Thanks,
> > Qu
> >
> >>>
> >>> Firstly, the while loop will always get at least one run.
> >>>
> >>> Secondly, in that loop, we either set ret to some error value and break,
> >>> or after at least one find_first_extent_item() and scrub_extent() call,
> >>> we increase cur_logical and reached the limit of the while loop and exit.
> >>>
> >>> So there is no possible routine to leave @ret uninitialized and returned
> >>> to caller.
> >>>
> >>> Thanks,
> >>> Qu
> >>>
> >>>> ---
> >>>>    fs/btrfs/scrub.c | 2 +-
> >>>>    1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
> >>>> index 4baa8e43d585..5ca7e5ffbc96 100644
> >>>> --- a/fs/btrfs/scrub.c
> >>>> +++ b/fs/btrfs/scrub.c
> >>>> @@ -3325,7 +3325,7 @@ static int scrub_simple_mirror(struct scrub_ctx *sctx,
> >>>>        const u32 max_length = SZ_64K;
> >>>>        struct btrfs_path path = {};
> >>>>        u64 cur_logical = logical_start;
> >>>> -     int ret;
> >>>> +     int ret = 0;
> >>>>
> >>>>        /* The range must be inside the bg */
> >>>>        ASSERT(logical_start >= bg->start &&
> >>
> >