Get the latest tech news
When eBPF pt_regs reads return garbage on the latest Linux kernels, blame Fred
TLDR; Starting from Linux kernel version 6.9 on x86_64, there’s a new config option CONFIG_X86_FRED enabled and it adds 16 bytes to the bottom of a task’s kernel stack area, so you’ll need to account for this extra padding in your “raw” kernel stack & pt_regs lookup code. Introduction I’ve been using Ubuntu 24.04 as my main eBPF development and testing platform without issues since its release. It is shipped with Linux kernel version 6. - Linux, Oracle, SQL performance tuning and troubleshooting - consulting & training.
The xcapture-next (v3) tool passively samples other threads’ activity & state by reading their task_struct kernel memory as a decoupled outside observer, without needing to inject any probes or tracepoints into other tasks execution paths. This gives us a pretty good starting point for building a top for wall-clock time tool on Linux, without any slowdown for all your other threads in the system (thanks to passive sampling with BPF task iterators). It’s not easy to read such compile-time constants or build-time settings from the eBPF kernel-land, so my current (unpublished) code snippet for detecting FRED in xcapture on x86 is roughly following.
Or read this on Hacker News