The function dentry_path_raw calls __dentry_path which has locks called inside the function, so itself or a wrapper cannot be used as the helper. You could traverse the dentry itself in the bpf progra

<iovisor-dev@...> wrote: All these are valid. For certain program types e.g., networking where pt_regs are not needed, you can already use -target bpf in clang. Check linux:tools/testing

Hi, Jiong, The patch looks good. Thanks for fixing the issue. Will merge soon. Yonghong <iovisor-dev@...> wrote:

Hi, Adrian, Thanks for comprehensive hacking report to make arm32 work! More comments below. <iovisor-dev@...> wrote: I look at the change. Mostly it is okay. In the code, you mentioned,

<cneirabustos@...> wrote: During linux plumbers conference, I talked to Eric Biederman (kernel namespace maintainer). The below is an example output of "stat -L /proc/self/ns/pid": -bash-4.3$ st

<iovisor-dev@...> wrote: Not sure what LLVM will do in this case for later "r1" access unless going through the real implementation. My hunch is LLVM should do a conversion from 32bit to

Hi, Jiong, The new patch looks good. I did some basic testing on net-next:samples/bpf and net-next:tools/testing/selftests/bpf and it works fine. All existing llvm unit tests are not impacted as well

Hi, Jiong, Thanks for the patch! It is a great start to support 32bit register in BPF. In the past, I have studied a little bit to see whether 32bit register support may reduce the number of unnecessa

iovisor-dev <iovisor-dev@...> wrote: The better way than export/import is prog/map pinning. Unfortunately, this is not available in bcc API yet.

Sorry. Resend with "plain text format" to satisfy xdp-newbies mailing list requirement.

Thanks, Jiong, The patch looks good. I have applied to llvm trunk. https://reviews.llvm.org/rL313055 A little bit more comments below. Right now, this optimization actually has been done in compiler s

Hi, Jiong, Thanks for the patch. Comments inlined. Right. We may need to separate out signed comparison vs. others. Will do that later. Sorry for the confusion caused by "ll". I tested your patch and

Hi, Carlos, Thanks for the prototyping. See comments below. iovisor-dev <iovisor-dev@...> wrote: We already have helper to get current task structure. From there, bpf_probe_read should g

I just push a patch (similar to your suggestion below but without assertion) which still has "ll" suffix for the constant, but no "ll" suffix for symbols. The reason is that we use "ll" in the asm pri

In kernel, you need to add your function proto to kprobe_prog_func_proto in kernel/trace/bpf_trace.c

Hi, Jiong, The patch looks great! I tested with a few bpf programs from kernel:samples/bpf/ directory. Your test case with verifier like input looks good. I will have a few suggestions later. I tested

Now I remember. The tracepoint get_stackid should still work. In kernel, we store the pt_regs in the first 8-byte unused args space and use it to walk through the stacks.

<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.

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

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?