All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Lorenz Bauer <lmb@cloudflare.com>,
	Martin KaFai Lau <kafai@fb.com>, Shuah Khan <shuah@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	kernel-team <kernel-team@cloudflare.com>,
	"open list:KERNEL SELFTEST FRAMEWORK" 
	<linux-kselftest@vger.kernel.org>,
	Network Development <netdev@vger.kernel.org>,
	bpf <bpf@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH bpf-next v2 2/4] selftests: bpf: Add helper to compare socket cookies
Date: Thu, 1 Oct 2020 10:11:23 -0700	[thread overview]
Message-ID: <CAADnVQJQeiyrN2JzOwV+zHDU5xg4TtpT0w9MgG6nujCK5z+GNQ@mail.gmail.com> (raw)
In-Reply-To: <CAEf4Bzbjzj3wwxX84bLi-PLy=9+Bpe1bTDt=t0qR5t=xEkNjwQ@mail.gmail.com>

On Thu, Oct 1, 2020 at 10:09 AM Andrii Nakryiko
<andrii.nakryiko@gmail.com> wrote:
>
> On Thu, Oct 1, 2020 at 12:25 AM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > On Wed, Sep 30, 2020 at 10:28:33AM +0100, Lorenz Bauer wrote:
> > > On Tue, 29 Sep 2020 at 16:48, Alexei Starovoitov
> > > <alexei.starovoitov@gmail.com> wrote:
> > >
> > > ...
> > >
> > > > There was a warning. I noticed it while applying and fixed it up.
> > > > Lorenz, please upgrade your compiler. This is not the first time such
> > > > warning has been missed.
> > >
> > > I tried reproducing this on latest bpf-next (b0efc216f577997) with gcc
> > > 9.3.0 by removing the initialization of duration:
> > >
> > > make: Entering directory '/home/lorenz/dev/bpf-next/tools/testing/selftests/bpf'
> > >   TEST-OBJ [test_progs] sockmap_basic.test.o
> > >   TEST-HDR [test_progs] tests.h
> > >   EXT-OBJ  [test_progs] test_progs.o
> > >   EXT-OBJ  [test_progs] cgroup_helpers.o
> > >   EXT-OBJ  [test_progs] trace_helpers.o
> > >   EXT-OBJ  [test_progs] network_helpers.o
> > >   EXT-OBJ  [test_progs] testing_helpers.o
> > >   BINARY   test_progs
> > > make: Leaving directory '/home/lorenz/dev/bpf-next/tools/testing/selftests/bpf'
> > >
> > > So, gcc doesn't issue a warning. Jakub did the following little experiment:
> > >
> > > jkbs@toad ~/tmp $ cat warning.c
> > > #include <stdio.h>
> > >
> > > int main(void)
> > > {
> > >         int duration;
> > >
> > >         fprintf(stdout, "%d", duration);
> > >
> > >         return 0;
> > > }
> > > jkbs@toad ~/tmp $ gcc -Wall -o /dev/null warning.c
> > > warning.c: In function ‘main’:
> > > warning.c:7:2: warning: ‘duration’ is used uninitialized in this
> > > function [-Wuninitialized]
> > >     7 |  fprintf(stdout, "%d", duration);
> > >       |  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >
> > >
> > > The simple case seems to work. However, adding the macro breaks things:
> > >
> > > jkbs@toad ~/tmp $ cat warning.c
> > > #include <stdio.h>
> > >
> > > #define _CHECK(duration) \
> > >         ({                                                      \
> > >                 fprintf(stdout, "%d", duration);                \
> > >         })
> > > #define CHECK() _CHECK(duration)
> > >
> > > int main(void)
> > > {
> > >         int duration;
> > >
> > >         CHECK();
> > >
> > >         return 0;
> > > }
> > > jkbs@toad ~/tmp $ gcc -Wall -o /dev/null warning.c
> > > jkbs@toad ~/tmp $
> >
> > That's very interesting. Thanks for the pointers.
> > I'm using gcc version 9.1.1 20190605 (Red Hat 9.1.1-2)
> > and I saw this warning while compiling selftests,
> > but I don't see it with above warning.c example.
> > clang warns correctly in both cases.
>
> I think this might be the same problem I fixed for libbpf with [0].
> Turns out, GCC explicitly calls out (somewhere in their docs) that
> uninitialized variable warnings work only when compiled in optimized
> mode, because some internal data structures used to detect this are
> only maintained in optimized mode build.
>
> Laurenz, can you try compiling your example with -O2?

All of my experiments I did with -O2.

>   [0] https://patchwork.ozlabs.org/project/netdev/patch/20200929220604.833631-2-andriin@fb.com/
>
> >
> > > Maybe this is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 ? The
> > > problem is still there on gcc 10. Compiling test_progs with clang does
> > > issue a warning FWIW, but it seems like other things break when doing
> > > that.
> >
> > That gcc bug has been opened since transition to ssa. That was a huge
> > transition for gcc. But I think the bug number is not correct. It points to a
> > different issue. I've checked -fdump-tree-uninit-all dump with and without
> > macro. They're identical. The tree-ssa-uninit pass suppose to warn, but it
> > doesn't. I wish I had more time to dig into it. A bit of debugging in
> > gcc/tree-ssa-uninit.c can probably uncover the root cause.

  reply	other threads:[~2020-10-01 17:11 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-28  9:08 [PATCH bpf-next v2 0/4] Sockmap copying Lorenz Bauer
2020-09-28  9:08 ` [PATCH bpf-next v2 1/4] bpf: sockmap: enable map_update_elem from bpf_iter Lorenz Bauer
2020-09-29  5:35   ` Martin KaFai Lau
2020-09-28  9:08 ` [PATCH bpf-next v2 2/4] selftests: bpf: Add helper to compare socket cookies Lorenz Bauer
2020-09-29  5:59   ` Martin KaFai Lau
2020-09-29 15:48     ` Alexei Starovoitov
2020-09-30  9:28       ` Lorenz Bauer
2020-10-01  7:23         ` Alexei Starovoitov
2020-10-01 17:09           ` Andrii Nakryiko
2020-10-01 17:11             ` Alexei Starovoitov [this message]
2020-10-02 10:08               ` Lorenz Bauer
2020-09-28  9:08 ` [PATCH bpf-next v2 3/4] selftests: bpf: remove shared header from sockmap iter test Lorenz Bauer
2020-09-28  9:08 ` [PATCH bpf-next v2 4/4] selftest: bpf: Test copying a sockmap and sockhash Lorenz Bauer
2020-09-29  6:06   ` Martin KaFai Lau
2020-09-29  9:21     ` Lorenz Bauer
2020-09-29 17:23       ` Martin KaFai Lau
2020-09-30  9:37         ` Lorenz Bauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAADnVQJQeiyrN2JzOwV+zHDU5xg4TtpT0w9MgG6nujCK5z+GNQ@mail.gmail.com \
    --to=alexei.starovoitov@gmail.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kafai@fb.com \
    --cc=kernel-team@cloudflare.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=lmb@cloudflare.com \
    --cc=netdev@vger.kernel.org \
    --cc=shuah@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.