On Mon, May 18, 2020 at 9:23 AM Tristan Mayfield <mayfieldtristan@xxxxxxxxx> 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 >
