Ashhad, At this moment, you can look at the following two tests: Test #10: py_test_brb Test #11: py_test_brb2 It does not really punt the packet to user space. But the example punts the packet to rout

Hi, William, Your analysis is correct. In this case, the error message could be improved. In general, a message like this "back-edge from insn 240 to 219" indicates a loop (back-edge ...). Compiler pr

<iovisor-dev@...> wrote: Just looked at the code. This seems a control plane application. You should not compile with "-target bpf". You should just use the default host one if you are i

You are right. In this case, r0 = bpf_map_lookup r2 = r0 r3 = r0 r4 = r0 r5 = r0 if (r0 != 0) <=== condition 1 r1 = 1 if (r0 != 0) r1 = 2 if (r3 != 0) *r3 = 0 ... If (r0 != 0) if false, the current ve

Tetsuo, I cannot reproduce the issue. The transformation from: dest = ctx->bx; to: dest = *(volatile uint64_t *)&ctx->bx; should be safe. I launched a psql console and did a query: ... yhs=> SELECT or

Hi, Tetsuo, You are right. The bug is actually introduced by my last patch. I just focused one aspect of issue and inadvertently introduced another *blocker* bug. I just pushed a patch. Thanks a lot f

Done. Sorry, I actually pushed the change to my yhs_dev branch last night, but forgot to generate a pull request ...

100% agree. Will work on a test case soon (maybe next week).

<iovisor-dev@...> wrote: If you try to print too much in a very short period of time, kernel may skip some of prints. perf_output is per process and bpf_trace_printk is global. Yes. You

<iovisor-dev@...> wrote: This is expected from current llvm implementation. For unpacked, the compiler is able to use field natural alignment to decide which load variant to use. For pac

I did an experiment with one of our internal bpf programs. The program has 1563 insns. Without Edward's patch: processed 13634 insns, stack depth 160 With Edward's patch: processed 15807 insns, stack

Frederik, The issue you are facing on prohibitive uprobe performance (even for sampling) has been discussed in this forum. The idea is to adopt maybe similar mechanism like dyninst or kerninst. We (me

cc'ing iovisor/bcc dev alias Jakub, I think this (bpf prog/map introspection) is a great idea. I am cc'ing iovisor/bcc alias so maybe similar functionality can be implemented in bcc as well. Thanks, Y

Just a wild guess. Could it be due to subsequent bpf invocations are not in the same cpu? The previous invocation reads timestamp in one cpu, and the next invocation gets timestamp in a different cpu.

errno 2 (ENOENT) means file does not exist. You can add additional print to check whether the file truly exists or not. <iovisor-dev@...> wrote:

<iovisor-dev@...> wrote: you may have to do that for an arbitrary filter. Maybe bpf code is simpler, there are some examples in how trace.py/argdist.py translating a simple spec to a bpf

CC to bcc mailing list as well. bpf_probe_read is not allowed in XDP programs. Your comparison may need to comparison not just starting offset, but also including the memory size so the whole write wo

Note that: R6=inv,min_value=4,max_value=65539,min_align=1,aux_off_align=2 "inv" means unknown value. Could you double check your program?

This is the problem: static inline uint16_t parse_tcp_pld(void *data, u64 nh_off, void *data_end) { uint16_t *pld = data + nh_off; if ((void*)&pld[1] > data_end) return 0; return pld; } return value s

<iovisor-dev@...> wrote: This won't work. get_stackid needs pt_regs so that it can walk through the frame to get stacks. Here for tracepoint, "args" is the tracepoint structure.