linux-kernel - Re: [PATCH] bcache: Zero initialize bucket in bch_allocator

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAK8P3a24tM1SB+gy1P9jdJ4077=DtOmgLvMLuNa9cj9RZGdxBg@mail.gmail.com>
Date:   Fri, 22 Mar 2019 15:36:12 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Coly Li <colyli@...e.de>
Cc:     Nathan Chancellor <natechancellor@...il.com>,
        Kent Overstreet <kent.overstreet@...il.com>,
        linux-bcache@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        clang-built-linux@...glegroups.com,
        Nick Desaulniers <ndesaulniers@...gle.com>
Subject: Re: [PATCH] bcache: Zero initialize bucket in bch_allocator_thread

On Fri, Mar 8, 2019 at 3:11 AM Coly Li <colyli@...e.de> wrote:
> On 2019/3/8 6:10 上午, Nathan Chancellor wrote:
> > When building with -Wsometimes-uninitialized, Clang warns:
> >
> > drivers/md/bcache/alloc.c:333:4: warning: variable 'bucket' is used
> > uninitialized whenever 'if' condition is false
> > [-Wsometimes-uninitialized]
> >
> > fifo_pop expands to a conditional depending on '!fifo_empty(...)', which
> > is the same condition as the while loop. It seems Clang can't piece
> > together that this condition will never been false as long as we are in
> > the while loop because they are the same condition. It's easy enough to
> > silence this warning by just explicitly zero initializing bucket.
> >
> > Link: https://github.com/ClangBuiltLinux/linux/issues/396
> > Signed-off-by: Nathan Chancellor <natechancellor@...il.com>
>
> Hi Nathan,
>
> Nice catch, I will add it to my for-test. Thanks.

I saw the same warning but came up with a nicer (IMHO) fix, see
https://lore.kernel.org/lkml/20190322143507.1256436-1-arnd@arndb.de/T/#u

        Arnd