The code wrongly assumed data_offset of probes would always be the same, while they are the same for kprobes, they might be different from static probes like sched_exec.
This diff grows the id map to store the data offset as well.
Funny thing, I fixed this same bug in another product as my first task in elastic, yet I managed to re-introduce it here, hooray.
Many thanks to @nicholasberlin for the assistance in tracking it down.
Another bug found with the upcoming multi kernel tester, I'm unpacking whichever rpms sound cool and running:
make initramfs.gz && ./ktest.sh initramfs.gz /tmp/pkg/lib/modules/5.14.0-427.40.1.el9_4.x86_64/vmlinuz
Results for kprobes:
linux-image-x86_64-5.10.103-1: ok
linux-image-x86_64-5.10.103-1-rt: ok
linux-image-x86_64-5.10.46-5: ok
linux-image-x86_64-5.10.46-5-cloud: ok
linux-image-x86_64-5.10.46-5-rt: ok
linux-image-x86_64-5.10.92-2: ok
linux-image-x86_64-5.10.92-2-cloud: ok
linux-image-x86_64-5.10.92-2-rt: ok
linux-3.10.0-1160.el7.x86_64: ok
linux-3.10.0-123.el7.x86_64: ok
linux-3.10.0-862.el7.x86_64: ok
linux-4.18.0-553.16.1.el8_10.x86_64: ok
linux-4.18.0-553.el8_10.x86_64: ok
linux-5.14.0-427.40.1.el9_4.x86_64: ok
The code wrongly assumed data_offset of probes would always be the same, while they are the same for kprobes, they might be different from static probes like sched_exec.
This diff grows the id map to store the data offset as well.
Funny thing, I fixed this same bug in another product as my first task in elastic, yet I managed to re-introduce it here, hooray.
Many thanks to @nicholasberlin for the assistance in tracking it down.
Another bug found with the upcoming multi kernel tester, I'm unpacking whichever rpms sound cool and running:
Results for kprobes: