On Tue, Oct 21, 2025 at 7:15 AM Andrey Grodzovsky <[email protected]> wrote: [...] > > commit a8b9cf62ade1bf17261a979fc97e40c2d7842353 > > Author: Masami Hiramatsu (Google) <[email protected]> > > Date: 1 year, 9 months ago > > ftrace: Fix DIRECT_CALLS to use SAVE_REGS by default > > > > commit bdbddb109c75365d22ec4826f480c5e75869e1cb > > Author: Petr Pavlu <[email protected]> > > Date: 1 year, 8 months ago > > > > tracing: Fix HAVE_DYNAMIC_FTRACE_WITH_REGS ifdef > > > > I tried to cherry-pick 60c8971899f3b34ad24857913c0784dab08962f0 > > and a8b9cf62ade1bf17261a979fc97e40c2d7842353, on top of 6.5.13 > > kernel. Then, fentry and fexit both work with livepatch. > > > I see, thanks for testing! Is the reason it breaks so often is because > this combination of having BPF > and llivepatch together on a system with intersection on same functions > as relatively rate event and > so regressions go easily unnoticed ? Isn't there any relevant automated > testing in upstream that checks for > those types of breaks ?
This case is not being covered because it is the intersection of tracing and livepatch. I am thinking about adding a BPF selftest to cover this case. Thanks, Song
