Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp634690pxk; Thu, 1 Oct 2020 10:13:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwhHm0ecwustf+pFN2oo7vzsQlVdqJ4rimj5x+fUVe3xqmU/ZFcHBFMaKVwBafFrP9ndLIE X-Received: by 2002:a05:6402:1593:: with SMTP id c19mr9371239edv.33.1601572396628; Thu, 01 Oct 2020 10:13:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601572396; cv=none; d=google.com; s=arc-20160816; b=FiJBjDEwvfXteX7vjIGlEatPJxSmHaQ1DCirKIzNUG9JxkXpo0owGJUvhAPqHvcRFQ 3XO4u0YwvZmHUL1uotaiR7eL9XHBbYu1HiR0+v4DNnw+u77EjAYw5wT/fphx6A1Cl2Rb rqbrzwM/XDu5yvX3fUm+8qYtPRufk8czK2o88Ug/hyqrO7f51+UqZz9HAW38g6lvZ0UC NCe2+nOeYBdbgP/u7chz8jybxpJTKAw/j/r10NG7h+m907Cg5VtpxF5ag7k6fgkg0rZt xGnW824aBHVNCReqe9qMyVSz40MkNdhBh6r+inNJ5Zd7Zl4C5aAUy77NKAUlek9ExAcJ t5ng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=4H6tqfFmYVuKV7tY9Iwf4g6YAYhBYzQtBBiSAWg+KwU=; b=XeMhT2w4ZLkAJD7ZTgV+qFFC1/DJPY1iaSRCfIGdScLKbO7022WeL7HSjT8ea2zL9+ 21RQ1EDoqZ1xH3mVAY+xjflx5i25A+0IexUKl6sLCGzKly5JXjWHFcFNfgzjLhUoKpJ+ YvOR7MpjehXEg+G3aSHDwf27xXi53jvUdndAavkxTQk4sj8SmCgcny+fyfgyfEf5hqsh mDrgrGmqrPyALAQ1ftEcttxF1nzabkhir7dg++yl9RlGVIf37xsUxMM6wRtShFa0Ch8C 4624qO8MgW3BIazD9kVyP+ujLS9eBggRhB5cEUcR2CChZaNQocjLvxgEvtj2Et5/FG12 Lh9Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=UhdBeefn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u10si3877860ejx.142.2020.10.01.10.12.53; Thu, 01 Oct 2020 10:13:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=UhdBeefn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732984AbgJARJX (ORCPT + 99 others); Thu, 1 Oct 2020 13:09:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54374 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732967AbgJARJV (ORCPT ); Thu, 1 Oct 2020 13:09:21 -0400 Received: from mail-yb1-xb42.google.com (mail-yb1-xb42.google.com [IPv6:2607:f8b0:4864:20::b42]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CC9F3C0613D0; Thu, 1 Oct 2020 10:09:20 -0700 (PDT) Received: by mail-yb1-xb42.google.com with SMTP id x20so4562052ybs.8; Thu, 01 Oct 2020 10:09:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4H6tqfFmYVuKV7tY9Iwf4g6YAYhBYzQtBBiSAWg+KwU=; b=UhdBeefnLTx7ql7vEdK8cudbbZajS39a2DmXV3qyKDVgCQT4Zsb20Fo1/E85oGsYaR 9PWHWg/S6odW5Pa4kcMVYeXmSp4NZx4fui3MiRCV7FEaCFLVE4UWJOnTySqLfP8dowEC qHOSmOZwY/jDrFoh6rIE/0m1O8OcVtMkJFmodW72mfJiqVfBsHwsVuzHePbdzzfCsjeB KJOK2JRV5sLmJECtBzFdbU6Zq+iWS4nVO0ILuxP4rh2Q2DkTv2x1WJUD6FYN0+BCGK1E olFjVyNIA+irX8IJAkELTuanBuoQF2UQHSlIfXU/D1cDbXTH5psSD48VFh2CoBKMZRp5 YTIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4H6tqfFmYVuKV7tY9Iwf4g6YAYhBYzQtBBiSAWg+KwU=; b=hLlHJDBalljYDRgWFx+zUQrBGuvbLl4hScolPdL6U8NjgPkd8+pxXXOajSIphyNYjx 6o5rc+IN1w0fkIB2eArsgc2N+MCfAw1iUlFg+/yuy1xlEHi+dI4GynnPd6GJKh6sLqQt oxjVP7GTo9bSJHyQVp0qa2glCC6WAiof35Z/b+PJi+WM1o4tr+1knAM5wZrEKWx6SI2F KhpzpYBU2/Sx3LRre2nvsGHWHLcRGxGsJdZHENAjjkdh/viR3IX8Z0ERKlbqhkzKSTDS MztRKion0bxe8QdS1BqzyJobq83lc3SHs+oijkpYtsnpAny2xQKkzEElMvu/9d3+63Pl hYZQ== X-Gm-Message-State: AOAM531qIwnCRsYb8CMtsVyXTtqco8Ct63+KfhNgI1wtDOIYNCFVKjSt 6Bgb2vPpaX4tkR/XG4/lur7e5ft4iUCJwzPBuF4= X-Received: by 2002:a25:2d41:: with SMTP id s1mr11517029ybe.459.1601572160010; Thu, 01 Oct 2020 10:09:20 -0700 (PDT) MIME-Version: 1.0 References: <20200928090805.23343-1-lmb@cloudflare.com> <20200928090805.23343-3-lmb@cloudflare.com> <20200929055851.n7fa3os7iu7grni3@kafai-mbp> <20201001072348.hxhpuoqmeln6twxw@ast-mbp.dhcp.thefacebook.com> In-Reply-To: <20201001072348.hxhpuoqmeln6twxw@ast-mbp.dhcp.thefacebook.com> From: Andrii Nakryiko Date: Thu, 1 Oct 2020 10:09:09 -0700 Message-ID: Subject: Re: [PATCH bpf-next v2 2/4] selftests: bpf: Add helper to compare socket cookies To: Alexei Starovoitov Cc: Lorenz Bauer , Martin KaFai Lau , Shuah Khan , Alexei Starovoitov , Daniel Borkmann , kernel-team , "open list:KERNEL SELFTEST FRAMEWORK" , Network Development , bpf , LKML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 1, 2020 at 12:25 AM Alexei Starovoitov wrote: > > On Wed, Sep 30, 2020 at 10:28:33AM +0100, Lorenz Bauer wrote: > > On Tue, 29 Sep 2020 at 16:48, Alexei Starovoitov > > 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/selft= ests/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/selfte= sts/bpf' > > > > So, gcc doesn't issue a warning. Jakub did the following little experim= ent: > > > > jkbs@toad ~/tmp $ cat warning.c > > #include > > > > 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 =E2=80=98main=E2=80=99: > > warning.c:7:2: warning: =E2=80=98duration=E2=80=99 is used uninitialize= d 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 > > > > #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? [0] https://patchwork.ozlabs.org/project/netdev/patch/20200929220604.8336= 31-2-andriin@fb.com/ > > > Maybe this is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D18501 ? Th= e > > 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 withou= t > macro. They're identical. The tree-ssa-uninit pass suppose to warn, but i= t > 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.