<tatsu-ab1@...> wrote: The concept and code looks okay to me. One thing is you could use RAW_TRACEPOINT_PROBE macro to be consistent with some other bcc tools raw tracepoint usages. Please submit

Hi, Jules, Just go to https://github.com/iovisor/bcc/issues and you can find quite some issues for you to investigate. Thanks! Yonghong

You can check return value of map.ringbuf_reserve(). If the reservation failed, you can notify user space through map, another side channel ringbuf, perf buf, etc. Depending on your program type and p

#bcc

<federico.parola@...> wrote: The source code is BPF_CALL_2(bpf_skb_pull_data, struct sk_buff *, skb, u32, len) { /* Idea is the following: should the needed direct read/write * test fail during

<federico.parola@...> wrote: This could be the case that linear data only covers up to the end of L4 header. In such cases, you can use bpf_skb_pull_data() helper to get more data into linear re

This is a good question. In earlier bpf days, the key MUST be from stack. Otherwise, the verifier will fail. Nowadays, things become better and keys can be from verifier recognizable memory regions (s

#bcc

<ys114321=gmail.com@...> wrote: I briefly looked at the perf and kernel code and experimented with perf dwarf mode. It is possible for bpf to copy user stack to user space. You could do

<bradley@...> wrote: The bpf stack unwinder is using the kernel one which is the frame pointer based and it may have issues with generated trampoline code which may mess up frame pointe

<bradley@...> wrote: I have no experience with perf-map-agent, but the following is what I guess: [perf-18047.map] is used to find the mapping between address and symbol. What does '[un

<bradley@...> wrote: I can see the file has been marked as deleted. 34603008 bytes in 33 allocations from stack [unknown] [jna9005484735610534564.tmp (deleted)] [unknown] [perf-31566.ma

Could you file an "issue" for the question? This issue, the questions/answers can be easily tracked. There are some answers in this issue: https://github.com/iovisor/bcc/issues/3093 To be accurate for

<federico.parola@...> wrote: Thanks, Federico and others. Maybe one of you can add it to the reference_guide.md? We do have events.perf_submit there. Thanks!

#bcc

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 u

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 := 3 endif KBUILD_C

Take a look at bcc tool runqlen.py. Did you get abnormal len with runqlen.py?

<williamfindlay@...> wrote: Does your key data structure have padding? Different padding values will cause different actual keys. If padding is not an issue in your case, could you const

I think your above assessment is kind of correct. For any read/write to stack in bpf programs, the stack offset must be known so the verifier knows exactly what the program tries to do. For helpers, v

I cannot remember details. Here, what "memset" did is to initialize related bytes in stack to 0. I guess maybe at that point bpf_probe_read_str requires an initialized memory? Right now, bpf_probe_rea

<dimolianis.marinos@...> wrote: eBPF/XDP. Right, BPF does not have TCAM style maps. If you organize data structure properly, you may be able to use LPM.

The closest map is lpm (trie) map. You may want to take a look.