On 22/11/2022 08:21, Kevin Brodsky wrote:
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.
It does or at least it should do. CONFIG_BPF is selected[1] by CONFIG_BPF_SYSCALL=y which has already been enabled here since
d0edd12ea75f ("morello: Enable docker in defconfig")
BPF actually works as is currently without these patches since we're not enforcing capabilities. Every cap from userspace just gets cut down to a 64b address and it all appears to work no problem.
Point taken on regression, all these commits should at least compile, I have tested that.
1: https://github.com/torvalds/linux/blob/v5.18/kernel/bpf/Kconfig#L28
+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...).
Okay thanks for the info on that, I wasn't aware of how defconfig worked. There's a lot of redundant additions here in that case, the only thing that actually needs to be here is:
CONFIG_FTRACE_SYSCALLS=y
That means this commit can be a lot smaller and it shouldn't really matter if it's at the start or end of the series since the ftrace series is already merged.
Thanks, Zach
Kevin