In eBPF, fentry and fexit programs (BPF_PROG_TYPE_TRACING) can target many of the same kernel functions as kprobe and kretprobe programs. How do they attach differently, and what does an fexit program see that a kretprobe cannot?

## The same targets, a different mechanism `fentry` and `fexit` programs are loaded as `BPF_PROG_TYPE_TRACING` with an expected attach type of `BPF_TRACE_FENTRY` or `BPF_TRACE_FEXIT`. They aim at kernel functions, just as kprobes do, but almost everything about how they get there is different. ## The BPF trampoline The kernel is compiled so that most functions begin with a patchable nop sequence at the very top — the site the ftrace machinery has always used. Attaching an fentry program installs a **BPF trampoline** at that site: generated machine code that saves the arguments in a known layout, calls your program, and continues into the real function. For `fexit`, the same trampoline also captures the return value and calls your program on the way out. Contrast that with a classic kprobe, whose baseline mechanism is a breakpoint instruction and a trap. Kprobes can be optimised into jumps, and the gap narrows when they are, but the trampoline path is designed for this from the start and is the cheaper of the two in practice. ## Typed arguments instead of registers A kprobe program's context is `struct pt_regs`, and you pull arguments out of it with architecture-specific macros. If you get the target's signature wrong, nothing complains — you silently read the wrong register. fentry/fexit require the kernel to carry BTF (built with `CONFIG_DEBUG_INFO_BTF`), which means the verifier knows the target function's prototype. Your program declares the arguments by name and type, and the verifier checks you against the real signature: attach to a function whose prototype does not match what you declared and the load fails rather than producing garbage. ```c SEC("fexit/do_unlinkat") int BPF_PROG(unlink_exit, int dfd, struct filename *name, long ret) { bpf_printk("do_unlinkat -> %ld", ret); return 0; } ``` The trailing `ret` parameter is the whole point of `fexit`. ## Why the entry/exit correlation problem disappears The classic tracing pattern is "time this function" or "log the arguments of calls that failed". With kprobes you need two programs: - a **kprobe** at entry, which sees the arguments and writes them into a hash map keyed by the thread id; - a **kretprobe** at return, which sees only the return value, looks the entry up in the map, emits the pair, and deletes the entry. That design has three real costs. It doubles the probe overhead and adds two map operations per call. It leaks map entries whenever a call never returns down the traced path — the entry sits there until something evicts it, which is why these tools use bounded or LRU maps. And it is lossy: a kretprobe works by replacing the return address, which requires an instance from a preallocated pool sized by `maxactive`. When more calls are in flight than there are instances, return probes are simply missed, and the miss count shows up in the kprobes listing in tracefs rather than anywhere your tool will notice. An `fexit` program collapses all of that into one program with the arguments and the return value in scope at once. No map, no correlation key, no misses from an exhausted instance pool. ## What you give up fentry/fexit are not a strict superset: - **Kernel and architecture support.** They arrived in Linux 5.5 and are supported on the main architectures, but on an old kernel or one built without BTF they are simply unavailable — which is why portable tooling still ships kprobe fallbacks. - **Function granularity only.** A kprobe can attach at a symbol *plus an offset*, anywhere inside a function. fentry attaches at the function's entry patch site, full stop. - **Untouchable functions.** Functions marked `notrace` or `noinstr`, and those the compiler inlined, have no patch site — the same fence kprobes hit, for the same reason. ## The interview framing When asked to choose, the answer is: on a modern kernel with BTF, reach for fentry/fexit first, because the arguments are typed and checked, the overhead is lower, and fexit removes an entire class of correlation bugs. Fall back to kprobe/kretprobe when the kernel is old, when BTF is absent, or when you need to probe at an offset inside a function rather than at its entry. And be able to say *why* the kretprobe pattern is lossy — that detail is the one that separates people who have read about eBPF from people who have shipped it.