Maybe you want to check with bcc issue https://github.com/iovisor/bcc/issues/728. Basically there is a kernel bug related to bpf_ktime_get_ns() and it is fixed in 4.9. Not sure about your kernel versi

All LLVM versions ( >= 3.7.1) should work for x86, but to use some features like BPF debug=8 to dump the source embedded byte code, you need llvm 6.0 or later.

You may check helper bpf_skb_change_tail(), which could serve your purpose.

The link to the llvm patch which generates .BTF and .BTF.ext sections: https://reviews.llvm.org/D52950

Hi, All, Below is the today's meeting notes. Thanks for joining the meeting. Please amend if you see any inaccurate or missing information. Yonghong ==== Discussion ==== Yonghong: - worked and upstrea

You can also cc llvm-commits.

<alexei.starovoitov@...> wrote: Currently, BTF does not deal with symbols, so that is why it is okay. llvm-objdump does not need symbol size either. It only needs symbol offset. that is why we d

Jiri, The change looks good. Could you generate a pull request against the bcc/iovisor github repository? Thanks! Yonghong

Looks good. Only one comment in the below. After you addressed it, you can send the patch to netdev with patch prefix [PATCH bpf-next]. Please move this definition to the end of file.

Currently, we are still in the design and prototyping stage. Will definitely share for comments once we got some concept design and RFC implementation.

bpf_get_current_pid_tgid() This may not enough as different name spaces could have the same tgid. Could you add comparison for pidns.nsid as well? You also need to tell how user can find nsid inside t

Yes, this approach should work too. I am thinking whether we could do it with one invocation of trace.py...

Okay, the htab_map_update_elem is indeed called, but you cannot trace it. The following kernel code in kernel/bpf/syscall.c explained the reason: /* must increment bpf_prog_active to avoid kprobe+bpf

<chaitanya.mgit@...> wrote: Which tracepoint you tried to attach? For kernel memory, a few kmem tracepoints are attached in memleak. If you want to attach a tracepoint only defined by the module

Please directly use the map lookup function for the specific map. For example, for hashmap, the verifier is smart enough to change the byte code to call the underlying hashmap map lookup function. ===

<mauricio.vasquez@...> wrote: I did not check the detailed implementation for percpu freelist implementation, but the general framework looks sound. I think the patch is ready to send to netdev

<mauricio.vasquez@...> wrote: Maybe we should "&& (arg_type == ARG_PTR_TO_MAP_VALUE || type != SCALAR_VALUE)"?

<mauricio.vasquez@...> wrote: There are still some values as it has bpf program doing "pop" operation.

bpf tracepoints have been removed from recent linux so the you need to use kprobe to trace update/delete. typical map_update_elem and map_delete_elem first argument is 'struct bpf_map *map', you can g

<mauricio.vasquez@...> wrote: Could you put the test in tools/testing/selftests/bpf? This way, it will be executed by various kernel testing infrastructure. For /sys/fs/bpf mount, you can check