linux-kernel - Re: Linux 6.3-rc3

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230320220631.GA637514@dev-arch.thelio-3990X>
Date:   Mon, 20 Mar 2023 15:06:31 -0700
From:   Nathan Chancellor <nathan@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Guenter Roeck <linux@...ck-us.net>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        dri-devel@...ts.freedesktop.org, linux-toolchains@...r.kernel.org,
        llvm@...ts.linux.dev
Subject: Re: Linux 6.3-rc3

On Mon, Mar 20, 2023 at 01:30:17PM -0700, Linus Torvalds wrote:
> On Mon, Mar 20, 2023 at 1:05 PM Guenter Roeck <linux@...ck-us.net> wrote:
> >
> > I have noticed that gcc doesn't always warn about uninitialized variables
> > in most architectures.
> 
> Yeah, I'm getting the feeling that when the gcc people were trying to
> make -Wmaybe-uninitialized work better (when moving it into "-Wall"),
> they ended up moving a lot of "clearly uninitialized" cases into it.
> 
> So then because we disable the "maybe" case (with
> -Wno-maybe-uninitialized) because it had too many random false
> positives, we end up not seeing the obvious cases either.

Right, this seems like a subtle difference in semantics between
-Wuninitialized between clang and GCC. My naive attempt to reduce the
problem with cvise spits out:

$ cat dev.i
void *host1x_probe___trans_tmp_1;
void host1x_unregister();
int host1x_probe_syncpt_irqhost1x_probe() {
  int err;
  if (host1x_probe___trans_tmp_1)
    return 2;
  if (err)
    host1x_unregister();
  return err;
}

$ gcc -O2 -Wall -c -o /dev/null dev.i
dev.i: In function ‘host1x_probe_syncpt_irqhost1x_probe’:
dev.i:7:6: warning: ‘err’ may be used uninitialized [-Wmaybe-uninitialized]
    7 |   if (err)
      |      ^
dev.i:4:7: note: ‘err’ was declared here
    4 |   int err;
      |       ^~~

$ clang -Wall -fsyntax-only dev.i
dev.i:7:7: warning: variable 'err' is uninitialized when used here [-Wuninitialized]
  if (err)
      ^~~
dev.i:4:10: note: initialize the variable 'err' to silence this warning
  int err;
         ^
          = 0
1 warning generated.

If I remove the first branch, both compilers show -Wuninitialized.

$ cat dev.i
void *host1x_probe___trans_tmp_1;
void host1x_unregister();
int host1x_probe_syncpt_irqhost1x_probe() {
  int err;
  if (err)
    host1x_unregister();
  return err;
}

$ gcc -O2 -Wall -c -o /dev/null dev.i
dev.i: In function ‘host1x_probe_syncpt_irqhost1x_probe’:
dev.i:5:6: warning: ‘err’ is used uninitialized [-Wuninitialized]
    5 |   if (err)
      |      ^
dev.i:4:7: note: ‘err’ was declared here
    4 |   int err;
      |       ^~~

$ clang -Wall -fsyntax-only dev.i
dev.i:5:7: warning: variable 'err' is uninitialized when used here [-Wuninitialized]
  if (err)
      ^~~
dev.i:4:10: note: initialize the variable 'err' to silence this warning
  int err;
         ^
          = 0
1 warning generated.

It seems like clang takes into account that the branch has no effect on
how uninitialized err is, although it does acknowledge there may be
control flow where err is not used uninitialized because it is not used
at all by stating "when used here". I guess GCC does not make this
distinction and places it under -Wmaybe-uninitialized. I could be
totally wrong though :)

Cheers,
Nathan