The post's own two listings show the silent-failure path by accident.
The live kprobe hooks `do_mmap` and reads `PT_REGS_PARM1` through `PARM4` as addr, len, prot and flags [9]. The fentry rewrite of the same hook declares its parameters as `struct file *file`, then addr, len, prot, with a comment saying that list follows the kernel prototype [15]. Line the two up and every position slides by one slot [16]. `PT_REGS_PARM3` expands to `rdx` on x86-64, and nothing verifies that `rdx` is holding `prot` [10]. The post names the consequence directly: when the kernel's signature moves, and it has, the offsets keep compiling and keep returning a number that is simply wrong [11]. An agent that reports a plausible value is much harder to notice than one that crashes.
The cost argument is weaker than the correctness argument, because the post supplies no measured per-call delta for either mechanism [19]. It asserts the ordering as a property of the install path rather than a tuning constant [17], which is a reasonable thing to claim about an exception versus a trampoline, and still not a number you can budget against. What can be bounded is the sensitivity, using the author's own framing of a function that fires a million times a second [3]. At that rate, one microsecond of added cost per call is one full CPU-second per second, or one core gone [18]. For that arithmetic to mean anything on your box, you need your call rate, your kernel, and your program body measured, because none of those three are in the source.
Then the adoption bill. The author's project sits at 13 kprobe attach points and uses that as the setting for when he would reach for fentry instead [8]. The 5.5-plus-BTF floor and the ftrace-attachable requirement [7] make that 13 separate eligibility checks, not one migration, and any function that fails the check keeps its `pt_regs` reader with the by-position risk intact.
Where I would spend the effort first is `fexit`, which delivers arguments and return value to a single program, while a `kretprobe` needs a paired entry probe and stashed state to do the same job [14]. That stashed state is code you wrote and now maintain: a map with a lifetime and a cleanup path.
On a single kernel version with BTF present, `BPF_PROG` plus fentry is the right default, and for the reason the post gives rather than the CPU one: a prototype that disagrees with BTF fails at load instead of quietly handing back the wrong register [12][13]. On a fleet with older kernels, the kprobe program stays in the tree as the fallback, and the argument-by-position hazard stays with it.
