retsnoop
retsnoop copied to clipboard
anakryiko
Investigate kernel error call stacks
So it turns out the board at work I wanted to use retsnoop on is running a 5.10 kernel (with no plans to upgrade, welcome to embedded), which doesn't have...
This one is different from https://github.com/anakryiko/retsnoop/issues/25. Here, the request is to just capture and symbolize user-space stack trace in addition to kernel stack trace, while still tracing only kernel functions....
Just leaving notes here as I don't think it's worth fixing per se, but this was rather a mess, so figured I might as well write it down for myself...
Just recording an idea. Support some small DSL (domain-specific language) for specifying extra conditions under which traces should be captured. E.g., this could be extra restrictions/conditions on entry function argument...
Something like: ``` $ sudo retsnoop -c bpf -- ./my_app arg1 arg2 ``` to start my_app and immediately trace it until it exits. This as a more usable alternative to...
We can rely on BTF and libbpf APIs (e.g., btf_dump__dump_type_data()) to capture and emit input arguments. Again, major considerations are usability: how to let user to specify when and what...
It would be nice to be able to use retsnoop's power to trace user-space binaries just as well as kernel itself (maybe both at the same time). This issue is...
This will allow simpler integration, won't require fork, will be easier to maintain and debug.
We have lots of host with kernel-4.19.x in our production environment, it will be nice if we can run retsnoop with external provided BTF infromation (like https://github.com/aquasecurity/btfhub).
Use retsnoop -e '*sys_sendto' -a ':net/ipv4/*.c' -S -T -l -vv cat /proc/kallsyms | grep udp_send_skb ffffffff9e2b5630 t udp_send_skb.isra.49 nm vmlinux | grep udp_send_skb ffffffff816b45e0 t udp_send_skb.isra.49 GCC has optimized udp_send_skb...
