linux-kernel - Re: [PATCH v2] selftests: sched_ext: Add sched

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: <87r08rnbra.fsf@all.your.base.are.belong.to.us>
Date: Mon, 07 Oct 2024 18:00:57 +0200
From: Björn Töpel <bjorn@...nel.org>
To: Mark Brown <broonie@...nel.org>
Cc: Tejun Heo <tj@...nel.org>, David Vernet <void@...ifault.com>, Shuah Khan
 <shuah@...nel.org>, linux-kernel@...r.kernel.org,
 linux-kselftest@...r.kernel.org, Björn Töpel
 <bjorn@...osinc.com>,
 bpf@...r.kernel.org, linux-riscv@...ts.infradead.org, Anders Roxell
 <anders.roxell@...aro.org>
Subject: Re: [PATCH v2] selftests: sched_ext: Add sched_ext as proper
 selftest target

Mark Brown <broonie@...nel.org> writes:

> On Mon, Oct 07, 2024 at 09:31:32AM +0200, Björn Töpel wrote:
>
>> When building the kselftest suite, e.g.:
>
>>   make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- \
>>     SKIP_TARGETS="" O=/output/foo -C tools/testing/selftests install
>
>> The expectation is that the sched_ext is included, cross-built, and
>> placed into /output/foo.
>
> When building for arm64 with this applied on top of mainline or -next
> I'm seeing:

Thanks for taking it for a spin!

>    make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -C tools/testing/selftests TARGETS=sched_ext SKIP_TARGETS="
>
> give
>
>   CLNG-BPF create_dsq.bpf.o
> In file included from create_dsq.bpf.c:9:
> /home/broonie/git/linux/tools/sched_ext/include/scx/common.bpf.h:33:17: error: use of undeclared identifier 'SCX_DSQ_FLAG_BUILTIN'
>    33 |         _Static_assert(SCX_DSQ_FLAG_BUILTIN,
>       |                        ^

This is most likely due to incorrect VMLINUX_BTF_PATHS, so that
vmlinux.h is incorrectly generated. Try grepping for
SCX_DSQ_FLAG_BUILTIN in vmlinux.h.

> and more (my system clang is clang 20).  It's also failing with a native
> x86_64 build in the same way.  I've run "make headers_install", it looks
> like clang is not getting told about the copy of the headers installed
> in ./usr/include:
>
> clang -g -D__TARGET_ARCH_x86 -mlittle-endian -I/home/broonie/git/linux/tools/testing/selftests/sched_ext/include -I/home/broonie/git/linux/tools/testing/selftests/sched_ext/include/bpf-compat -I/home/broonie/git/linux/tools/testing/selftests/sched_ext/build/include -I/home/broonie/git/linux/tools/include/uapi -I/home/broonie/git/linux/tools/sched_ext/include -I/home/broonie/git/linux/include -idirafter /usr/lib/llvm-20/lib/clang/20/include -idirafter /usr/local/include -idirafter /usr/include/x86_64-linux-gnu -idirafter /usr/include  -Wall -Wno-compare-distinct-pointer-types -Wno-incompatible-function-pointer-types -O2 -mcpu=v3 -target bpf -c create_dsq.bpf.c -o /home/broonie/git/linux/tools/testing/selftests/sched_ext/build/obj/sched_ext/create_dsq.bpf.o

The sched_ext BPF programs relies on a vmlinux.h, which is generated
using bpftool and the vmlinux with BTF information. Have you built a
kernel with BTF support?

>> Add CROSS_COMPILE, OUTPUT, and TARGETS support to the sched_ext
>> selftest. Also, remove some variables that were unused by the
>> Makefile.
>
>> +ifneq ($(CROSS_COMPILE),)
>> +DEFAULT_BPFTOOL := $(OUTPUT_DIR)/host/sbin/bpftool
>> +HOST_OBJ_DIR := $(OBJ_DIR)/host/bpftool
>> +HOST_LIBBPF_OUTPUT := $(OBJ_DIR)/host/libbpf/
>> +HOST_LIBBPF_DESTDIR := $(OUTPUT_DIR)/host/
>> +HOST_DESTDIR := $(OUTPUT_DIR)/host/
>> +else
>> +DEFAULT_BPFTOOL := $(OUTPUT_DIR)/sbin/bpftool
>> +HOST_OBJ_DIR := $(OBJ_DIR)/bpftool
>> +HOST_LIBBPF_OUTPUT := $(OBJ_DIR)/libbpf/
>> +HOST_LIBBPF_DESTDIR := $(OUTPUT_DIR)/
>> +HOST_DESTDIR := $(OUTPUT_DIR)/
>> +endif
>
> This won't detect a cross compile when building using LLVM as that
> doesn't need to set CROSS_COMPILE, it can use the same binaries for all
> targets.  There's runes in the Makefile for the mm selftests for
> identifying the target architecture, though actually I'm wondering if
> it's worth just always building the host copy and never having to worry
> if the target build is a cross build or not?  It's obvious overhead in
> the native case though if we actually need the target copy.

Yeah, that would indeed simplify things! I'll spin a v3 with that (and
wait for more feedback).


Thanks for testing the patch!
Björn