Re: [PATCH] perf build: Build error in libbpf missing initialization

[Jakub Kicinski]

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:  
> >> In linux-next tree compiling the perf tool with additional make flags
> >> "EXTRA_CFLAGS="-Wp,-D_FORTIFY_SOURCE=2 -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=1 EXTRA_CFLAGS="-Wp,-D_FORTIFY_SOURCE=2 -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 âbpf_perf_event_read_simpleâ:
> >> libbpf.c:2342:6: error: âretâ may be used uninitialized in this
> >> 			function [-Werror=maybe-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 target 'libbpf.o' failed
> >>
> >> Fix this warning and add an addition check at the beginning
> >> of the while loop.
> >>
> >> Cc: Alexei Starovoitov <ast@xxxxxxxxxx>
> >> Cc: Daniel Borkmann <daniel@xxxxxxxxxxxxx>
> >>
> >> Suggested-by: Jakub Kicinski <jakub.kicinski@xxxxxxxxxxxxx>
> >> Signed-off-by: Thomas Richter <tmricht@xxxxxxxxxxxxx>  
> > 
> > Ah, you already sent this, LGTM, thanks Thomas!
> >   
> >>  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 long size,
> >>  
> >>  	begin = base + data_tail % size;
> >>  	end = base + data_head % size;
> >> +	if (begin == end)
> >> +		return LIBBPF_PERF_EVENT_ERROR;
> >>  
> >>  	while (begin != end) {
> >>  		struct perf_event_header *ehdr;  
> 
> One question though, any objections to go for something like the below instead?
> I doubt we ever hit this in a 'normal' situation, and given we already test 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):
> 
> 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 = mem;
>         __u64 data_tail = header->data_tail;
>         __u64 data_head = header->data_head;
> +       int ret = LIBBPF_PERF_EVENT_ERROR;
>         void *base, *begin, *end;
> -       int ret;
> 
>         asm volatile("" ::: "memory"); /* in real code it should be smp_rmb() */
>         if (data_head == 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 :)