From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jakub Kicinski Subject: Re: [PATCH] perf build: Build error in libbpf missing initialization Date: Fri, 27 Jul 2018 12:56:32 -0700 Message-ID: <20180727125632.33634af5@cakuba.netronome.com> References: <20180727082126.87530-1-tmricht@linux.ibm.com> <20180727105923.2d5da6aa@cakuba.netronome.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Thomas Richter , ast@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, heiko.carstens@de.ibm.com, brueckner@linux.vnet.ibm.com, schwidefsky@de.ibm.com To: Daniel Borkmann Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Fri, 27 Jul 2018 21:31:01 +0200, Daniel Borkmann wrote: > On 07/27/2018 07:59 PM, Jakub Kicinski wrote: > > On Fri, 27 Jul 2018 10:21:26 +0200, Thomas Richter wrote: =20 > >> In linux-next tree compiling the perf tool with additional make flags > >> "EXTRA_CFLAGS=3D"-Wp,-D_FORTIFY_SOURCE=3D2 -O2" > >> causes a compiler error. It is the warning > >> 'variable may be used uninitialized' > >> which is treated as error: > >> > >> I compile it using a FEDORA 28 installation, my gcc compiler version: > >> gcc (GCC) 8.0.1 20180324 (Red Hat 8.0.1-0.20) > >> > >> The file that causes the error is tools/lib/bpf/libbpf.c > >> > >> Here is the error message: > >> > >> [root@p23lp27] # make V=3D1 EXTRA_CFLAGS=3D"-Wp,-D_FORTIFY_SOURCE=3D2 = -O2" > >> [...] > >> Makefile.config:849: No openjdk development package found, please > >> install JDK package, e.g. openjdk-8-jdk, java-1.8.0-openjdk-devel > >> Warning: Kernel ABI header at 'tools/include/uapi/linux/if_link.h' > >> differs from latest version at 'include/uapi/linux/if_link.h' > >> CC libbpf.o > >> libbpf.c: In function =E2=80=98bpf_perf_event_read_simple=E2=80=99: > >> libbpf.c:2342:6: error: =E2=80=98ret=E2=80=99 may be used uninitialize= d in this > >> function [-Werror=3Dmaybe-uninitialized] > >> int ret; > >> ^ > >> cc1: all warnings being treated as errors > >> mv: cannot stat './.libbpf.o.tmp': No such file or directory > >> /home6/tmricht/linux-next/tools/build/Makefile.build:96: recipe for ta= rget 'libbpf.o' failed > >> > >> Fix this warning and add an addition check at the beginning > >> of the while loop. > >> > >> Cc: Alexei Starovoitov > >> Cc: Daniel Borkmann > >> > >> Suggested-by: Jakub Kicinski > >> Signed-off-by: Thomas Richter =20 > >=20 > > Ah, you already sent this, LGTM, thanks Thomas! > > =20 > >> tools/lib/bpf/libbpf.c | 2 ++ > >> 1 file changed, 2 insertions(+) > >> > >> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c > >> index 73465caa33ba..66965ca96113 100644 > >> --- a/tools/lib/bpf/libbpf.c > >> +++ b/tools/lib/bpf/libbpf.c > >> @@ -2349,6 +2349,8 @@ bpf_perf_event_read_simple(void *mem, unsigned l= ong size, > >> =20 > >> begin =3D base + data_tail % size; > >> end =3D base + data_head % size; > >> + if (begin =3D=3D end) > >> + return LIBBPF_PERF_EVENT_ERROR; > >> =20 > >> while (begin !=3D end) { > >> struct perf_event_header *ehdr; =20 >=20 > One question though, any objections to go for something like the below in= stead? > I doubt we ever hit this in a 'normal' situation, and given we already te= st for > the begin and end anyway, we could just avoid the extra test altogether. = I could > change it to the below if you're good as well (no need to resend anything= ): >=20 > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c > index d881d37..1aafdbe 100644 > --- a/tools/lib/bpf/libbpf.c > +++ b/tools/lib/bpf/libbpf.c > @@ -2273,8 +2273,8 @@ bpf_perf_event_read_simple(void *mem, unsigned long= size, > volatile struct perf_event_mmap_page *header =3D mem; > __u64 data_tail =3D header->data_tail; > __u64 data_head =3D header->data_head; > + int ret =3D LIBBPF_PERF_EVENT_ERROR; > void *base, *begin, *end; > - int ret; >=20 > asm volatile("" ::: "memory"); /* in real code it should be smp_r= mb() */ > if (data_head =3D=3D data_tail) No real objection, although as a matter of personal taste I'm not a big fan of initializing err/ret variables unless the code is explicitly structured to make use of it. Here it looks slightly more like silencing a compiler warning, hence my preference to address the actual cause of the warning rather than catch all. I guess one could argue the other way, i.e. if the loop never run (and therefore ret was not overwritten) there must be *some* error. I like verbose/explicit code I guess.. Up to you :)