+ Yonghong, On Tue, May 2, 2023 at 10:56 AM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > On Tue, 2 May 2023 10:40:28 -0700 > Song Liu <song@xxxxxxxxxx> wrote: > > > We hit the following hiccup a couple times in the past few months: > > > > A function is marked as "inline", but the compiler decided not to inline it. > > Since "inline" implies "notrace" since [1], this function doesn't have > > fentry/mcount. When we built livepatch for this function, kpatch-build > > failed with: > > > > xxx.o: function yyy has no fentry/mcount call, unable to patch > > > > This is not a deal breaker, as we can usually modify the patch to work > > around it. But I wonder whether we still need "inline" to imply "notrace". > > Can we remove this to make livepatch a little easier? > > The history behind this is that there were cases that functions that were > inlined, were in critical paths that could cause crashes if they were > traced. In testing they never triggered because the developer's compiler > inlined them. Then on someone else's machine, the compiler decided not to > inline the function and the system crashed. It was hell to debug because I > was not able to reproduce the issue, as my compiler would always keep the > function inlined! > > But a lot has changed since then. I've implemented the > "ftrace_test_recursion_trylock()" that catches pretty much all recursive > bugs (and can ever report when they happen). So I may be open to removing > the "notrace" from "inline". Thanks for the history! Let's try to remove this constraint. Song
