libbpf-tools: fix fentry prog in tcprtt #3757
Conversation
This commit fixes judgement if tcp_rcv_established fentry exists and fentry prog by introducing BPF_CORE_READ. Signed-off-by: chendotjs <chendotjs@gmail.com>
chendotjs
requested review from
4ast,
brendangregg,
drzaeus77,
goldshtn and
yonghong-song
as code owners
| @@ -56,7 +57,7 @@ int BPF_PROG(tcp_rcv, struct sock *sk) | |||
| if (!histp) | |||
| return 0; | |||
| ts = (struct tcp_sock *)(sk); | |||
| srtt = ts->srtt_us >> 3; | |||
| srtt = BPF_CORE_READ(ts, srtt_us) >> 3; | |||
There was a problem hiding this comment.
I think pointer chasing should work without BPF_CORE_READ.
There was a problem hiding this comment.
No, got error:
; srtt = ts->srtt_us >> 3;
65: (61) r2 = *(u32 *)(r6 +1640)
access beyond struct sock at off 1640 size 4
processed 40 insns (limit 1000000) max_states_per_insn 0 total_states 4 peak_states 4 mark_read 4
Any suggestion? @chenhengqi
There was a problem hiding this comment.
You can use bpf_skc_to_tcp_sock if you have a recent kernel.
There was a problem hiding this comment.
@chendotjs What is your version of clang? Have you tried the new version of clang?
There was a problem hiding this comment.
$ clang -v
clang version 13.0.0
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-pc-linux-gnu/11.1.0
Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0
Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
There was a problem hiding this comment.
Thanks for reply. @chenhengqi @ethercflow
bpf_skc_to_tcp_sock does work but was added to kernel since 5.9.
clang 13 is the latest stable release right now, released at 4 October 2021. So I guess upgrading clang might not work, but I will still try building latest clang 14 (In-Progress) from source to have a try.
There was a problem hiding this comment.
@chendotjs Which distribution and kernel are you using? I tried centos stream 8, but it did not reproduce your problem
➜ libbpf-tools git:(master) ✗ uname -r
4.18.0-305.10.2.el8_4.x86_64
➜ libbpf-tools git:(master) ✗ clang -v
clang version 11.0.0 (Red Hat 11.0.0-1.module_el8.4.0+587+5187cac0)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/8
Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/8
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
➜ libbpf-tools git:(master) ✗There was a problem hiding this comment.
- debian 11 with kernel 5.10.0 and clang 11.0.1
- archlinux with kernel 5.15.7 and clang 13.0.0
neither works without BPF_CORE_READ.
There was a problem hiding this comment.
@chendotjs You're right, I used bpftool prog list and found that kprobe was loaded. I don't know why we can't pointer chasing with fentry here. cc @anakryiko @yonghong-song
There was a problem hiding this comment.
Because kernel only knows that sk is struct sock and struct sock doesn't have srtt_us field. So yes, you need BPF_CORE_READ().
|
cc @ethercflow |
This commit fixes judgement if tcp_rcv_established fentry exists and fentry prog by introducing BPF_CORE_READ. Signed-off-by: chendotjs <chendotjs@gmail.com>
This commit fixes judgement if tcp_rcv_established fentry exists and fentry prog by introducing BPF_CORE_READ.
Signed-off-by: chendotjs chendotjs@gmail.com