Understood. I was a bit surprised to read that this area ended up taking months of follow-up work....
One thing I am still trying to understand is what the preferred debuggability/observability direction would be for existing tailcall-heavy BPF/XDP deployments. Tail calls are already used in practice as a program decomposition mechanism, especially in XDP pipelines, and that leaves tail-called leaf programs harder to observe today. If fentry on tail-called programs is not something you'd want upstream, is there another direction you would recommend for improving observability/debuggability of such existing deployments? 2026年3月28日(土) 0:21 Alexei Starovoitov <[email protected]>: > > On Fri, Mar 27, 2026 at 8:12 AM Takeru Hayasaka <[email protected]> wrote: > > > > Hi Alexei > > > > Thanks, and Sorry, I sent an older changelog from while I was still > > iterating on this, and it described the issue incorrectly. > > > > My changelog made this sound like an IBT/non-IBT-specific issue, but > > that was wrong. On current kernels, fentry on tail-called programs is > > not supported in either case. Only the regular fentry patch site is > > patched; there is no tail-call landing patching in either case, so > > disabling IBT does not make it work. > > > > What this series was trying to do was add support for fentry on > > tail-called x86 programs. The non-IBT part was only about a bug in my > > initial implementation of that support, not the underlying motivation. > > > > The motivation is observability of existing tailcall-heavy BPF/XDP > > programs, where tail-called leaf programs are currently a blind spot for > > fentry-based debugging. > > I get that, but I'd rather not open this can of worms. > We had enough headaches when tailcalls, fentry, subprogs are combined. > Like this set: > https://lore.kernel.org/all/[email protected]/ > and the followups.
