Messages in this thread | | | Date | Tue, 18 Oct 2022 17:02:41 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH] ftrace,kcfi: Separate ftrace_stub() and ftrace_stub_graph() |
| |
On Tue, Oct 18, 2022 at 10:21:00AM -0400, Steven Rostedt wrote: > On Tue, 18 Oct 2022 14:35:15 +0200 > Peter Zijlstra <peterz@infradead.org> wrote: > > > Different function signatures means they needs to be different > > functions; otherwise CFI gets upset. > > This is due to this commit: > > commit b83b43ffc6e4b514ca034a0fbdee01322e2f7022 > Author: Steven Rostedt (VMware) <rostedt@goodmis.org> > Date: Tue Oct 15 09:00:55 2019 -0400 > > fgraph: Fix function type mismatches of ftrace_graph_return using ftrace_stub > > The C compiler is allowing more checks to make sure that function pointers > are assigned to the correct prototype function. Unfortunately, the function > graph tracer uses a special name with its assigned ftrace_graph_return > function pointer that maps to a stub function used by the function tracer > (ftrace_stub). The ftrace_graph_return variable is compared to the > ftrace_stub in some archs to know if the function graph tracer is enabled or > not. This means we can not just simply create a new function stub that > compares it without modifying all the archs. > > Instead, have the linker script create a function_graph_stub that maps to > ftrace_stub, and this way we can define the prototype for it to match the > prototype of ftrace_graph_return, and make the compiler checks all happy! > > > Perhaps its time to just modify all the archs and get rid of that hack.
Ideally yes, but given kCFI is in Linus' tree now, I didn't feel like fixing up all archs in a hurry.
Mark mentioned that most archs can probably move to a common empty C function for each stub.
| |