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  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]
Date:   Sun, 8 Dec 2019 13:35:08 -0800
From:   Linus Torvalds <>
To:     David Miller <>
Cc:     Andrew Morton <>,
        Netdev <>,
        Linux Kernel Mailing List <>
Subject: Re: [GIT] Networking

On Sun, Dec 8, 2019 at 1:20 AM David Miller <> wrote:
>   git://


This introduces a new warning for me:

    drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c: In function
warning: ‘n’ may be used uninitialized in this function
      332 |  struct neighbour *n;
          |                    ^

which is very annoying.

The cause is commit 6c8991f41546 ("net: ipv6_stub: use
ip6_dst_lookup_flow instead of ip6_dst_lookup") which changed
mlx5e_route_lookup_ipv6() to use ipv6_dst_lookup_flow() which returns
an error pointer, so it then does

        if (IS_ERR(dst))
                return PTR_ERR(dst);

instead of

        if (ret < 0)
                return ret;

in the old code.

And that then means that the caller, which does

        err = mlx5e_route_lookup_ipv6(priv, mirred_dev, &out_dev, &route_dev,
                                      &fl6, &n, &ttl);
        if (err)
                return err;

and now gcc no longer sees that 'n' is always initialized when 'err'
is zero. Because gcc apparently thinks that the

        if (IS_ERR(dst))
                return PTR_ERR(dst);

thing can result in a zero return value (I guess the cast from a
64-bit pointer to an 'int' is where it thinks "ok, that cast might
lose high bits and become zero even when the original was tested to
have a range where that will not happen).

Anyway - the code is not buggy, but the new warning is simply not
acceptable. We keep the build warning free even if it's gcc not being
clever enough to see that "if it's uninitialized, we never get to the
location where it's used".

I don't know what the networking pattern for this is, but I did this
in the merge

--      struct neighbour *n;
++      struct neighbour *n = NULL;

and I'm not happy about having gotten a pull request that has this
kind of shit in it, especially since it was _known_ shit.

It could have been that people had compilers that didn't see this
problem. But no.

I see that Stephen Rothwell reported it four days ago, and David seems
to have even answered it.

And yet that warning was still there in the pull request.


David, this is not acceptable.  You don't introduce new warnings in the tree.

It doesn't matter one whit whether the warning is a false positive. A
false positive warning will then be the cause of ignoring subsequent
real warnings, which makes false positive warnings completely

Fix your mindset, and stop sending me garbage.


Powered by blists - more mailing lists