Hi, when I looked into the runqlen script yesterday, I found that, sadly, I misunderstood the "queue length" all the time not only the "length" part but also the "queue" part. Queue ===== Only CFS

On Tue, Mar 2, 2021 at 08:22 PM, Andrii Nakryiko wrote: On Tue, Mar 2, 2021 at 4:42 PM <bg.salunke09@...> wrote: Thanks Andrii, for detailed answer. Yes you are right, I'm looking for CO-RE. Basically

Yes, correct. Yes, you can, if you have vmlinux image with DWARF information in it. You can use pahole tool like this to add .BTF section to vmlinux image: pahole -J <path-to-vmlinux-image> You

Thanks Andrii, for detailed answer. Yes you are right, I'm looking for CO-RE. Basically I'm trying to build the eBPF program which can run on any linux kernel version using libbpf What I understood

"Andrii Nakryiko" <andrii.nakryiko@...> writes: Yeah, that looks like a RHEL/CentOS kernel version number, which means the 4.18 bit is mostly fiction at this point (at least as far as BPF

/sys/kernel/btf/vmlinux appeared in 5.4 kernel (upstream version). If you see it on 4.18, that means someone backported the changes. But for BPF CO-RE (which I assume is what you are referring to) to

bg.salunke09@... asked: The basic support appears to have been added by commit e83b9f55448afce3fe1abcd1d10db9584f8042a6 Author: Andrii Nakryiko <andriin@...> Date: Tue Apr 2 09:49:50 2019

Hi, I'm looking into BTF and it's use case. Based on the document I understood to run BPF programs across different kernel versions, it needs to build with libbpf which depends on the BTF

You can use bpf tail calls today. You can look at bcc/tests/cc/test_prog_table.cc for an example. bcc does not support subprogram yet. In the future we do plan to be more libbpf compatible so we can

"Tristan Mayfield" <mayfieldtristan@...> writes: OK, I'll try to explain this one: Think of __builtin_memcpy() as a macro: it just compiles down to regular program instructions copying the

Hello, I was wondering if BCC implements the new BPF feature (as of kernel 5.10) to allow BPF programs to utilize both BPF tail calls and BPF subprograms. This behavior is described near the end of

-- Andrii <mayfieldtristan@...> wrote: vmlinux usually refers to kernel image binary. /sys/kernel/btf/vmlinux is not that, it's only the BTF data. So CO-RE needs kernel BTF, not necessarily

Thank you to both Andrii and Toke! It's been extremely helpful to read your responses. Having conversations like these really helps me when I go into the source code and try to understand the overall

Ah, neat, didn't know that (and I tend to lump all that together mentally anyway). You're welcome, and thanks for confirming my understanding :) -Toke

As far as CO-RE BPF program compilation goes, there shouldn't be much difference between the latest kernel vs some older one. In case of libbpf-tools, some of the tools might be using some features

"Tristan Mayfield" <mayfieldtristan@...> writes: Right, in that case that's probably just because the struct in question is next to some other valid memory (not sure where tracepoints

Toke, thanks for the quick response! Yes, I was checking the bpf_probe_read return values, and was reading the number of bytes expected, so nothing wrong there! Now that you mention CO-RE, it does

"Tristan Mayfield" <mayfieldtristan@...> writes: bpf_probe_read() will happily read any piece of kernel memory, it doesn't respect kernel boundaries. So if the call succeeded (you did check the

The other day I was in the process of porting a little libbpf application from Ubuntu 20 (Linux 5.4) to CentOS 8 (Linux 4.18). This program uses tracepoint:tcp:tcp_send_reset. Here's the relevant BPF

Unfortunately, the value is defined in Makefile, ``` ifeq ($(CONFIG_KASAN_SW_TAGS), y) KASAN_SHADOW_SCALE_SHIFT := 4 else ifeq ($(CONFIG_KASAN_GENERIC), y) KASAN_SHADOW_SCALE_SHIFT :=