On Mon, May 18, 2020 at 9:23 AM Tristan Mayfield
<mayfieldtristan@...> wrote:
Thanks for the reply Andrii.
Managed to get a build working outside of the kernel tree for BPF programs.
The two major things that I learned were that first, the order in which files are
included in the build command is more important than I previously thought.
The second thing was learning how clang deals with asm differently than gcc.
I had to use samples/bpf/asm_goto_workaround.h to fix those errors.
The meat of the makefile is as follows:
CLANGINC := /usr/lib/llvm-10/lib/clang/10.0.0/include
INC_FLAGS := -nostdinc -isystem $(CLANGINC)
EXTRA_FLAGS := -O3 -emit-llvm
BTW, everyone seems to be using -O2 for compiling BPF programs. Not
sure how well-supported -O3 will be.
[...]
I suspect that these warnings come from my aggressive warning flags during
compilation rather than from actual issues in the kernel.
Right, pinning map or program doesn't ensure that program is still
attached to whatever BPF hook you attached to it. As you mentioned,
XDP, tc, cgroup-bpf programs are persistent. We are actually moving
towards the model of auto-detachment for those as well. See recent
activity around bpf_link. The solution with bpf_link to make such
attachments persistent is through pinning **link** itself, not program
or map. bpf_link is relatively recent addition, so on older kernels
you'd have to make sure you still have some process around that would
keep BPF attachment FD around.
I have been looking at the commits surrounding the pinning of bpf_link. It looks like it's only
working in kernel 5.7? I did actually go through and attempt to attach links for kprobes,
tracepoints, and raw_tracepoints in kernel 5.4 but, as you suggested, it seems unsupported.
I have yet to try on kernel 5.5-5.7 so I'll take a look this week or next.
As I mentioned before, with basic functionality in place here, I'm interested in working on
some sort of BPF tutorial similar to the XDP tutorial (https://github.com/xdp-project/xdp-tutorial)
with perhaps a more in-depth look at the technology included as well.
I'm still fuzzy on the relationship between bpf(2) and perf(1). Would it be correct to say that for
tracepoints, kprobes, and uprobes BPF leverages perf "under the hood" while for XDP and tc,
this is more like classic BPF in that it's implementation doesn't involve perf?
"classic BPF" is entirely different thing, don't use that term in this
context, it will just confuse people.
perf is used as a means to trigger BPF program execution for
tracepoint and kprobes. It is, essentially, a BPF hook provider, if
you will. For XDP, BPF hook is provided by networking layer and
drivers. For cgroup BPF programs, hooks are "provided", in a sense, by
cgroup subsystem. So perf is just one of many ways to specify where
and when BPF program is going to be executed, and with what context.
If that's the case then is the bpf_link object the tool to bridge BPF and perf? I noticed that when
checking for pinned BPF programs with bpftool in kernel 5.4 that unless a kprobe, tracepoint,
or uprobe is listed in "bpftool perf list", the program doesn't seem to be running. Is the use of
perf to load BPF programs potentially a way to make them "headless" instead of pinning the bpf_link objects?
no, bpf_link is a way to marry BPF hook with BPF program. It's not
specific to perf or XDP, or whatever. Actually, right now perf-based
BPF hooks (kprobe, tracepoint) actually do not create a bpf_link under
cover, so you won't be able to pin them.
Regardless, I'm excited to have a more reliable build system than I have in the past. I think I'll start looking more into CO-RE and libbpf on kernels 5.5-5.7.
Awesome, have fun!
Hope everyone is staying healthy out there,
Tristan
