On 17/11/2022 13:53, Zachary Leaf wrote:
On 16/11/2022 14:50, Tudor Cretu wrote:
On 15-11-2022 09:08, Zachary Leaf wrote:
Enable support for running eBPF in the kernel. JIT compilation is disabled for now.
In addition enable syscall tracing options that are required to use BPF_PROG_TYPE_TRACEPOINT.
Signed-off-by: Zachary Leaf zachary.leaf@arm.com
.../configs/morello_transitional_pcuabi_defconfig | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/configs/morello_transitional_pcuabi_defconfig b/arch/arm64/configs/morello_transitional_pcuabi_defconfig index 2c0798c18553..0d32128d6610 100644 --- a/arch/arm64/configs/morello_transitional_pcuabi_defconfig +++ b/arch/arm64/configs/morello_transitional_pcuabi_defconfig @@ -145,5 +145,18 @@ CONFIG_MAGIC_SYSRQ=y CONFIG_DEBUG_FS=y # CONFIG_SCHED_DEBUG is not set # CONFIG_DEBUG_PREEMPT is not set -# CONFIG_FTRACE is not set CONFIG_MEMTEST=y +# BPF
Comments are nice, but are not typical to defconfigs.
Ack
+CONFIG_BPF=y
Does this actually build right now? If not, in the complete series this patch should be last, or at any rate at a point where it does not stop the kernel from building. This is mainly for the purpose of bisectability - no commit should introduce a regression.
+CONFIG_BPF_SYSCALL=y
This one is already set on line 6.
Ack
+CONFIG_NET_CLS_BPF=m +CONFIG_NET_ACT_BPF=m
Are we loading modules? I am not sure why we need these.
You're right, it doesn't appear that we're building anything as a non-builtin module currently (i.e. no ...=m), at least based on my .config. It doesn't look like these modules are even built for whatever reason - build-scripts probably need updating. Do modules work?
Not at the minute, in fact I have bumped into that issue again just yesterday and created a ticket to track this [1].
[1] https://git.morello-project.org/morello/kernel/linux/-/issues/41
As for what it's for, it's for network traffic-control classifier/actions, so basically classifying packets and taking some action based on that. eBPF can be used for both those via BPF_PROG_TYPE_SCHED_CLS/..._SCHED_ACT program types.
man 8 tc-bpf: https://man7.org/linux/man-pages/man8/tc-bpf.8.html
This article gives a good intro/overview: https://qmonnet.github.io/whirl-offload/2020/04/11/tc-bpf-direct-action/
In any case I didn't check or test this functionality so will remove for now in v2 unless anyone has different opinions.
Makes sense, that may be a bit too much for the defconfig.
+CONFIG_BPF_JIT=n +CONFIG_HAVE_EBPF_JIT=y +# for BPF tracepoint support +CONFIG_BPF_EVENTS=y +CONFIG_TRACEPOINTS=y +CONFIG_HAVE_SYSCALL_TRACEPOINTS=y +CONFIG_PERF_EVENTS=y +CONFIG_FTRACE=y +CONFIG_FTRACE_SYSCALLS=y
Whenever you modify a defconfig, it's useful to also run "make savedefconfig" and compare the created defconfig with the one you modified. In that way, you can identify if there are conflicts, duplicates, or redundant entries.
Good tip.
In fact this exactly how the defconfig should be updated: run `make savedefconfig` then overwrite the defconfig with its output. This creates a "canonical" defconfig that is stable for a given set of options. It does mean you can't customise it in any way though.
On that note, Téo is right: `# CONFIG_XYZ is not set` is used instead of `CONFIG_XYZ=n` in config files (yes such comments do do something, and no I don't know why it is done this way...).
Kevin