Please join us tomorrow for our bi-weekly call. As usual, this meeting is open to everybody and completely optional. You might be interested to join if: You want to know what is going on in BPF

Hello, My name is Usman. I am interested to contribute an example code for OpenStack VLAN traffic monitoring. Regarding this can you please guide me how I can submit my code on GitHub (Since I could

Interesting... thanks for explanation. OK, I will submit the patch. Thanks William

Now I remembered that we had this issue before in bcc. it is a compiler optimization likes this: if (...) *(ctx + 60) else *(ctx + 56) The compiler translates it to if (...) ptr = ctx +

Hi, William, Do you have a test (just compile and load) to demonstrate the problem? I would like to understand why the compiler generates r1+0 and whether we could possibly avoid

Hi, We're hitting a BPF verifier error saying "dereference of modified ctx ptr R1 off=36+0, ctx+const is allowed, ctx+const+const is not " but actually the 2nd const is 0. I don't know why compiler

Applied to bpf-next, thanks Paul!

Thanks for the review. I've sent a refactored patchset that uses check_helper_mem_access().

This patch adds new test cases for accesses to map values from map helpers. Signed-off-by: Paul Chaignon <paul.chaignon@...> --- tools/testing/selftests/bpf/test_verifier.c | 266

Helpers that expect ARG_PTR_TO_MAP_KEY and ARG_PTR_TO_MAP_VALUE can only access stack and packet memory. Allow these helpers to directly access map values by passing registers of type

Currently, helpers that expect ARG_PTR_TO_MAP_KEY and ARG_PTR_TO_MAP_VALUE can only access stack and packet memory. This patchset allows these helpers to directly access map values by passing

We should reuse check_helper_mem_access() here which covers all three cases from above already and simplifies the code a bit. Ditto. Thanks, Daniel

This patch adds new test cases for accesses to map values from map helpers. Signed-off-by: Paul Chaignon <paul.chaignon@...> --- tools/testing/selftests/bpf/test_verifier.c | 266

Helpers that expect ARG_PTR_TO_MAP_KEY and ARG_PTR_TO_MAP_VALUE can only access stack and packet memory. Allow these helpers to directly access map values by passing registers of type

Currently, helpers that expect ARG_PTR_TO_MAP_KEY and ARG_PTR_TO_MAP_VALUE can only access stack and packet memory. This patchset allows these helpers to directly access map values by passing

Thank you very much for your reply . it is more clear now. Best regards

From the "kprobe__" syntax, I'm guessing that you're using bcc. The bcc rewriter will replace the second argument of your function with a dereference on ctx (ctx->di on x86) [1]. It won't check that

BPF does not understand function signature. BPF program has access to the register context (struct pt_regs *ctx). If you use BCC, when you initiate (compile) your BPF program, the compiler rewrites

<iovisor-dev@...> wrote: You can access through arguments or through "current" task pointer. What exactly you want access on which kprobe? More information will help people to understand

On 04/18/2018 10:03 PM, Jesper Dangaard Brouer via iovisor-dev wrote: [...] > What does bpftool use BFD for? It's used for the prog JIT dump in order to disassemble the instructions.