public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <jakub.kicinski@netronome.com>
To: Thomas Richter <tmricht@linux.ibm.com>
Cc: daniel@iogearbox.net, 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,
	wangnan0@huawei.com
Subject: Re: [PATCH v2] perf build: Build error in libbpf with EXTRA_CFLAGS="-Wp,-D_FORTIFY_SOURCE=2 -O2"
Date: Wed, 25 Jul 2018 18:48:35 -0700	[thread overview]
Message-ID: <20180725184835.5d37bef4@cakuba.netronome.com> (raw)
In-Reply-To: <20180725072126.2232-1-tmricht@linux.ibm.com>

On Wed, 25 Jul 2018 09:21:26 +0200, Thomas Richter wrote:
> commit a5b8bd47dcc57 ("bpf tools: Collect eBPF programs from their own sections")

Hmm.. are you sure it's not 531b014e7a2f ("tools: bpf: make use of
reallocarray") that caused the issue?  That commit made us switch from
XSI-compliant to GNU-specific strerror_r() implementation..

/me checks

Yes it looks like 531b014e7a2f~ builds just fine.

Daniel, did you try to apply v1 to the bpf tree?  Perhaps there is a
confusion about the trees here, if this is caused by my recent change
it's a bpf-next material.  strerror() works, but strerror_r() seems
nicer, so perhaps we could keep it if the patch worked in bpf-next?

> causes a compiler error when building the perf tool in the linux-next tree.
> 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"
> [...]
> make -f /home6/tmricht/linux-next/tools/build/Makefile.build
> 	dir=./util/scripting-engines obj=libperf
> libbpf.c: In function ‘bpf_object__elf_collect’:
> libbpf.c:811:15: error: ignoring return value of ‘strerror_r’,
> 		declared with attribute warn_unused_result [-Werror=unused-result]
>      strerror_r(-err, errmsg, sizeof(errmsg));
>                ^
> 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
> 
> Since this is the only occurance of strerror_r() replace it
> by strerror(). The additional functionality of strerror_r() to
> copy the error message into the supplied buffer is not needed.
> This is also consistant with all the other pr_warning() statements
> in this file which all use strerror().
> 
> Also fixes a possible initialization issue.
> 
> Cc: Wang Nan <wangnan0@huawei.com>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
>
>  tools/lib/bpf/libbpf.c | 7 ++-----
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 955f8eafbf41..f9eb68ff2f4f 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -806,11 +806,8 @@ static int bpf_object__elf_collect(struct bpf_object *obj)
>  			err = bpf_object__add_program(obj, data->d_buf,
>  						      data->d_size, name, idx);
>  			if (err) {
> -				char errmsg[STRERR_BUFSIZE];
> -
> -				strerror_r(-err, errmsg, sizeof(errmsg));
>  				pr_warning("failed to alloc program %s (%s): %s",
> -					   name, obj->path, errmsg);
> +					   name, obj->path, strerror(-err));
>  			}
>  		} else if (sh.sh_type == SHT_REL) {
>  			void *reloc = obj->efile.reloc;
> @@ -2334,7 +2331,7 @@ bpf_perf_event_read_simple(void *mem, unsigned long size,
>  	__u64 data_tail = header->data_tail;
>  	__u64 data_head = header->data_head;
>  	void *base, *begin, *end;
> -	int ret;
> +	int ret = 0;
>  
>  	asm volatile("" ::: "memory"); /* in real code it should be smp_rmb() */
>  	if (data_head == data_tail)

This looks like a separate issue.  The ret variable should really be
enum bpf_perf_event_ret, so could you please initialize it to one of the
values of this enum?

The uninitilized condition can only happen if (data_head != data_tail)
but at the same time (data_head % size == data_tail % size) which
should never really happen...  Perhaps initializing to
LIBBPF_PERF_EVENT_ERROR would make sense?

Or better still adding:

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index f732237610e5..fa5a25945f19 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -2289,6 +2289,8 @@ bpf_perf_event_read_simple(void *mem, unsigned long size,
 
        begin = base + data_tail % size;
        end = base + data_head % size;
+       if (being == end)
+               return LIBBPF_PERF_EVENT_ERROR;
 
        while (begin != end) {
                struct perf_event_header *ehdr;

  reply	other threads:[~2018-07-26  1:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-25  7:21 [PATCH v2] perf build: Build error in libbpf with EXTRA_CFLAGS="-Wp,-D_FORTIFY_SOURCE=2 -O2" Thomas Richter
2018-07-26  1:48 ` Jakub Kicinski [this message]
2018-07-27  2:16   ` Daniel Borkmann
2018-07-27  7:22     ` Thomas-Mich Richter
2018-07-27 17:57       ` Jakub Kicinski
2018-07-27 18:29         ` Daniel Borkmann

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=20180725184835.5d37bef4@cakuba.netronome.com \
    --to=jakub.kicinski@netronome.com \
    --cc=ast@kernel.org \
    --cc=brueckner@linux.vnet.ibm.com \
    --cc=daniel@iogearbox.net \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=tmricht@linux.ibm.com \
    --cc=wangnan0@huawei.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