netdev - Re: [PATCH bpf-next 2/3] selftests: bpf: extend sub-register mode compilation to all bpf object files

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190211040412.wvulodgvz3jcnida@ast-mbp>
Date:   Sun, 10 Feb 2019 20:04:13 -0800
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Jiong Wang <jiong.wang@...ronome.com>
Cc:     daniel@...earbox.net, netdev@...r.kernel.org,
        oss-drivers@...ronome.com
Subject: Re: [PATCH bpf-next 2/3] selftests: bpf: extend sub-register mode
 compilation to all bpf object files

On Fri, Feb 08, 2019 at 05:41:20PM +0000, Jiong Wang wrote:
> At the moment, we only do extra sub-register mode compilation on bpf object
> files used by "test_progs". These object files are really loaded and
> executed.
> 
> This patch further extends sub-register mode compilation to all bpf object
> files, even those without corresponding runtime tests. Because this could
> help testing LLVM sub-register code-gen, kernel bpf selftest has much more
> C testcases with reasonable size and complexity compared with LLVM
> testsuite which only contains unit tests.
> 
> There were some file duplication inside BPF_OBJ_FILES_DUAL_COMPILE which
> is removed now.
> 
> Reviewed-by: Jakub Kicinski <jakub.kicinski@...ronome.com>
> Signed-off-by: Jiong Wang <jiong.wang@...ronome.com>
> ---
>  tools/testing/selftests/bpf/Makefile | 21 ++++++++-------------
>  1 file changed, 8 insertions(+), 13 deletions(-)
> 
> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
> index 383d2ff..70b2570 100644
> --- a/tools/testing/selftests/bpf/Makefile
> +++ b/tools/testing/selftests/bpf/Makefile
> @@ -35,20 +35,15 @@ BPF_OBJ_FILES = \
>  	sendmsg4_prog.o sendmsg6_prog.o test_lirc_mode2_kern.o \
>  	get_cgroup_id_kern.o socket_cookie_prog.o test_select_reuseport_kern.o \
>  	test_skb_cgroup_id_kern.o bpf_flow.o netcnt_prog.o test_xdp_vlan.o \
> -	xdp_dummy.o test_map_in_map.o test_spin_lock.o test_map_lock.o
> -
> -# Objects are built with default compilation flags and with sub-register
> -# code-gen enabled.
> -BPF_OBJ_FILES_DUAL_COMPILE = \
> -	test_pkt_access.o test_pkt_access.o test_xdp.o test_adjust_tail.o \
> -	test_l4lb.o test_l4lb_noinline.o test_xdp_noinline.o test_tcp_estats.o \
> +	xdp_dummy.o test_map_in_map.o test_spin_lock.o test_map_lock.o \
> +	test_pkt_access.o test_xdp.o test_adjust_tail.o test_l4lb.o \
> +	test_l4lb_noinline.o test_xdp_noinline.o test_tcp_estats.o \
>  	test_obj_id.o test_pkt_md_access.o test_tracepoint.o \
> -	test_stacktrace_map.o test_stacktrace_map.o test_stacktrace_build_id.o \
> -	test_stacktrace_build_id.o test_get_stack_rawtp.o \
> -	test_get_stack_rawtp.o test_tracepoint.o test_sk_lookup_kern.o \
> -	test_queue_map.o test_stack_map.o
> +	test_stacktrace_map.o test_stacktrace_build_id.o \
> +	test_get_stack_rawtp.o test_sk_lookup_kern.o test_queue_map.o \
> +	test_stack_map.o
>  
> -TEST_GEN_FILES = $(BPF_OBJ_FILES) $(BPF_OBJ_FILES_DUAL_COMPILE)
> +TEST_GEN_FILES = $(BPF_OBJ_FILES)
>  
>  # Also test sub-register code-gen if LLVM + kernel both has eBPF v3 processor
>  # support which is the first version to contain both ALU32 and JMP32
> @@ -58,7 +53,7 @@ SUBREG_CODEGEN := $(shell echo "int cal(int a) { return a > 0; }" | \
>  			$(LLC) -mattr=+alu32 -mcpu=probe 2>&1 | \
>  			grep 'if w')

build and test servers can be different.
Would it make sense to use -mcpu=v3 instead of -mcpu=probe ?

Also while testing test_progs_32 fails like this:
libbpf: failed to open ./bpf_flow.o: No such file or directory
libbpf: failed to open ./test_spin_lock.o: No such file or directory
test_spin_lock:bpf_prog_load errno 2

Do you see the same ?