From: Daniel Borkmann <daniel@iogearbox.net>
To: Jakub Kicinski <jakub.kicinski@netronome.com>
Cc: Thomas Richter <tmricht@linux.ibm.com>,
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
Subject: Re: [PATCH] perf build: Build error in libbpf missing initialization
Date: Sat, 28 Jul 2018 21:30:34 +0200 [thread overview]
Message-ID: <f78f1675-b34d-a21e-1714-4acc9e53414f@iogearbox.net> (raw)
In-Reply-To: <20180727125632.33634af5@cakuba.netronome.com>
On 07/27/2018 09:56 PM, Jakub Kicinski wrote:
> 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@kernel.org>
>>>> Cc: Daniel Borkmann <daniel@iogearbox.net>
>>>>
>>>> Suggested-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>>>> Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
>>>
>>> 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 :)
Ok, I pushed this variant out to the bpf tree since it also is affected there.
Thanks a lot everyone!
prev parent reply other threads:[~2018-07-28 19:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-27 8:21 [PATCH] perf build: Build error in libbpf missing initialization Thomas Richter
2018-07-27 17:59 ` Jakub Kicinski
2018-07-27 19:31 ` Daniel Borkmann
2018-07-27 19:56 ` Jakub Kicinski
2018-07-28 19:30 ` Daniel Borkmann [this message]
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=f78f1675-b34d-a21e-1714-4acc9e53414f@iogearbox.net \
--to=daniel@iogearbox.net \
--cc=ast@kernel.org \
--cc=brueckner@linux.vnet.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=jakub.kicinski@netronome.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=schwidefsky@de.ibm.com \
--cc=tmricht@linux.ibm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).