On Wed, Mar 24, 2021 at 5:46 AM Rasmus Villemoes <li...@rasmusvillemoes.dk> wrote: > > On 23/03/2021 08.47, Peter Zijlstra wrote: > > On Mon, Mar 22, 2021 at 05:29:21PM -0400, Steven Rostedt wrote: > >> On Mon, 22 Mar 2021 22:18:17 +0100 > >> Arnd Bergmann <a...@kernel.org> wrote: > >> > >>> I think the code works correctly on all architectures we support because > >>> both 'int' and 'long' are returned in a register with any unused bits > >>> cleared. > >>> It is however undefined behavior in C because 'int' and 'long' are not > >>> compatible types, and the calling conventions don't have to allow this. > >> > >> Static calls (and so do tracepoints) currently rely on these kind of > >> "undefined behavior" in C. This isn't the only UB that it relies on. > > > > Right, most of the kernel lives in UB. That's what we have -fwrapv > > -fno-strict-aliassing and lots of other bits for, to 'fix' the stupid C > > standard. > > > > This is one more of them, so just ignore the warning and make it go > > away: > > > > -Wno-cast-function-type > > > > seems to be the magic knob. > > > > That can be done for now, but I think something has to be done if CFI is > to become a thing. > > Sami, what happens if you try to boot a > CONFIG_CFI_CLANG+CONFIG_PREEMPT_DYNAMIC kernel?
Seems to boot just fine. CFI instrumentation is only for compiler-generated indirect calls. Casting functions to different types is fine as long as you don't end up calling them using an incorrect pointer type. Sami