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 <[email protected]>
Cc: Daniel Borkmann <[email protected]>
Suggested-by: Jakub Kicinski <[email protected]>
Signed-off-by: Thomas Richter <[email protected]>
---
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;
--
2.16.4
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 <[email protected]>
> Cc: Daniel Borkmann <[email protected]>
>
> Suggested-by: Jakub Kicinski <[email protected]>
> Signed-off-by: Thomas Richter <[email protected]>
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;
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 <[email protected]>
>> Cc: Daniel Borkmann <[email protected]>
>>
>> Suggested-by: Jakub Kicinski <[email protected]>
>> Signed-off-by: Thomas Richter <[email protected]>
>
> 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)
Thanks,
Daniel
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 <[email protected]>
> >> Cc: Daniel Borkmann <[email protected]>
> >>
> >> Suggested-by: Jakub Kicinski <[email protected]>
> >> Signed-off-by: Thomas Richter <[email protected]>
> >
> > 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 :)
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 <[email protected]>
>>>> Cc: Daniel Borkmann <[email protected]>
>>>>
>>>> Suggested-by: Jakub Kicinski <[email protected]>
>>>> Signed-off-by: Thomas Richter <[email protected]>
>>>
>>> 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!