bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Jiri Olsa <jolsa@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	netdev@vger.kernel.org, bpf@vger.kernel.org,
	Yonghong Song <yhs@fb.com>, Martin KaFai Lau <kafai@fb.com>,
	David Miller <davem@redhat.com>,
	John Fastabend <john.fastabend@gmail.com>,
	Jesper Dangaard Brouer <hawk@kernel.org>,
	Wenbo Zhang <ethercflow@gmail.com>,
	KP Singh <kpsingh@chromium.org>, Andrii Nakryiko <andriin@fb.com>,
	bgregg@netflix.com, Florent Revest <revest@chromium.org>,
	Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH 7/9] bpf: Compile the BTF id whitelist data in vmlinux
Date: Wed, 13 May 2020 11:29:40 -0700	[thread overview]
Message-ID: <20200513182940.gil7v5vkthhwck3t@ast-mbp.dhcp.thefacebook.com> (raw)
In-Reply-To: <20200506132946.2164578-8-jolsa@kernel.org>

On Wed, May 06, 2020 at 03:29:44PM +0200, Jiri Olsa wrote:
> Squeezing in the BTF id whitelist data into vmlinux object
> with BTF section compiled in, with following steps:
> 
>   - generate whitelist data with bpfwl
>     $ bpfwl .tmp_vmlinux.btf kernel/bpf/helpers-whitelist > ${whitelist}.c
> 
>   - compile whitelist.c
>     $ gcc -c -o ${whitelist}.o ${whitelist}.c
> 
>   - keep only the whitelist data in ${whitelist}.o using objcopy
> 
>   - link .tmp_vmlinux.btf and ${whitelist}.o into $btf_vmlinux_bin_o}
>     $ ld -r -o ${btf_vmlinux_bin_o} .tmp_vmlinux.btf ${whitelist}.o
> 
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> ---
>  Makefile                |  3 ++-
>  scripts/link-vmlinux.sh | 20 +++++++++++++++-----
>  2 files changed, 17 insertions(+), 6 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index b0537af523dc..3bb995245592 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -437,6 +437,7 @@ OBJSIZE		= $(CROSS_COMPILE)size
>  STRIP		= $(CROSS_COMPILE)strip
>  endif
>  PAHOLE		= pahole
> +BPFWL		= $(srctree)/tools/bpf/bpfwl/bpfwl
>  LEX		= flex
>  YACC		= bison
>  AWK		= awk
> @@ -493,7 +494,7 @@ GCC_PLUGINS_CFLAGS :=
>  CLANG_FLAGS :=
>  
>  export ARCH SRCARCH CONFIG_SHELL BASH HOSTCC KBUILD_HOSTCFLAGS CROSS_COMPILE LD CC
> -export CPP AR NM STRIP OBJCOPY OBJDUMP OBJSIZE READELF PAHOLE LEX YACC AWK INSTALLKERNEL
> +export CPP AR NM STRIP OBJCOPY OBJDUMP OBJSIZE READELF PAHOLE BPFWL LEX YACC AWK INSTALLKERNEL
>  export PERL PYTHON PYTHON3 CHECK CHECKFLAGS MAKE UTS_MACHINE HOSTCXX
>  export KBUILD_HOSTCXXFLAGS KBUILD_HOSTLDFLAGS KBUILD_HOSTLDLIBS LDFLAGS_MODULE
>  
> diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
> index d09ab4afbda4..dee91c6bf450 100755
> --- a/scripts/link-vmlinux.sh
> +++ b/scripts/link-vmlinux.sh
> @@ -130,16 +130,26 @@ gen_btf()
>  	info "BTF" ${2}
>  	LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1}
>  
> -	# Create ${2} which contains just .BTF section but no symbols. Add
> +	# Create object which contains just .BTF section but no symbols. Add
>  	# SHF_ALLOC because .BTF will be part of the vmlinux image. --strip-all
>  	# deletes all symbols including __start_BTF and __stop_BTF, which will
>  	# be redefined in the linker script. Add 2>/dev/null to suppress GNU
>  	# objcopy warnings: "empty loadable segment detected at ..."
>  	${OBJCOPY} --only-section=.BTF --set-section-flags .BTF=alloc,readonly \
> -		--strip-all ${1} ${2} 2>/dev/null
> -	# Change e_type to ET_REL so that it can be used to link final vmlinux.
> -	# Unlike GNU ld, lld does not allow an ET_EXEC input.
> -	printf '\1' | dd of=${2} conv=notrunc bs=1 seek=16 status=none
> +		--strip-all ${1} 2>/dev/null
> +
> +	# Create object that contains just .BTF_whitelist_* sections generated
> +	# by bpfwl. Same as BTF section, BTF_whitelist_* data will be part of
> +	# the vmlinux image, hence SHF_ALLOC.
> +	whitelist=.btf.vmlinux.whitelist
> +
> +	${BPFWL} ${1} kernel/bpf/helpers-whitelist > ${whitelist}.c
> +	${CC} -c -o ${whitelist}.o ${whitelist}.c
> +	${OBJCOPY} --only-section=.BTF_whitelist* --set-section-flags .BTF=alloc,readonly \
> +                --strip-all ${whitelist}.o 2>/dev/null
> +
> +	# Link BTF and BTF_whitelist objects together
> +	${LD} -r -o ${2} ${1} ${whitelist}.o

Thank you for working on it!
Looks great to me overall. In the next rev please drop RFC tag.

My only concern is this extra linking step. How many extra seconds does it add?

Also in patch 3:
+               func = func__find(str);
+               if (func)
+                       func->id = id;
which means that if somebody mistyped the name or that kernel function
got renamed there will be no warnings or errors.
I think it needs to fail the build instead.

If additional linking step takes another 20 seconds it could be a reason
to move the search to run-time.
We already have that with struct bpf_func_proto->btf_id[].
Whitelist could be something similar.
I think this mechanism will be reused for unstable helpers and other
func->btf_id mappings, so 'bpfwl' name would change eventually.
It's not white list specific. It generates a mapping of names to btf_ids.
Doing it at build time vs run-time is a trade off and it doesn't have
an obvious answer.

  reply	other threads:[~2020-05-13 18:29 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-06 13:29 [RFCv2 0/9] bpf: Add d_path helper Jiri Olsa
2020-05-06 13:29 ` [PATCH 1/9] " Jiri Olsa
2020-05-14 22:06   ` Andrii Nakryiko
2020-05-15 14:59     ` Jiri Olsa
2020-05-06 13:29 ` [PATCH 2/9] bpf: Add d_path whitelist Jiri Olsa
2020-05-06 13:29 ` [PATCH 3/9] bpf: Add bpfwl tool to construct bpf whitelists Jiri Olsa
2020-05-14 22:20   ` Andrii Nakryiko
2020-05-15 14:58     ` Jiri Olsa
2020-05-06 13:29 ` [PATCH 4/9] bpf: Allow nested BTF object to be refferenced by BTF object + offset Jiri Olsa
2020-05-14 22:32   ` Andrii Nakryiko
2020-05-06 13:29 ` [PATCH 5/9] bpf: Add support to check on BTF id whitelist for d_path helper Jiri Olsa
2020-05-06 13:29 ` [PATCH 6/9] bpf: Compile bpfwl tool at kernel compilation start Jiri Olsa
2020-05-14 22:38   ` Andrii Nakryiko
2020-05-15 14:57     ` Jiri Olsa
2020-05-06 13:29 ` [PATCH 7/9] bpf: Compile the BTF id whitelist data in vmlinux Jiri Olsa
2020-05-13 18:29   ` Alexei Starovoitov [this message]
2020-05-14  8:05     ` Jiri Olsa
2020-05-14 22:46       ` Andrii Nakryiko
2020-05-15 14:57         ` Jiri Olsa
2020-05-28 17:23         ` Jiri Olsa
2020-05-29 20:48           ` Andrii Nakryiko
2020-05-31 15:10             ` Jiri Olsa
2020-06-01 19:06               ` Andrii Nakryiko
2020-06-02  8:16                 ` Jiri Olsa
2020-05-06 13:29 ` [PATCH 8/9] selftests/bpf: Add test for d_path helper Jiri Olsa
2020-05-14 22:48   ` Andrii Nakryiko
2020-05-15 14:57     ` Jiri Olsa
2020-05-06 13:29 ` [PATCH 9/9] selftests/bpf: Add verifier " Jiri Olsa

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=20200513182940.gil7v5vkthhwck3t@ast-mbp.dhcp.thefacebook.com \
    --to=alexei.starovoitov@gmail.com \
    --cc=andriin@fb.com \
    --cc=ast@kernel.org \
    --cc=bgregg@netflix.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@redhat.com \
    --cc=ethercflow@gmail.com \
    --cc=hawk@kernel.org \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kafai@fb.com \
    --cc=kpsingh@chromium.org \
    --cc=netdev@vger.kernel.org \
    --cc=revest@chromium.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=yhs@fb.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).