On Mon, Apr 18, 2016 at 02:12:09PM +0200, Michael Matz wrote: > > . It can also be solved by having just one NOP after the function label, > and a number of them before, then no thread can be in the nop pad. That > seems to indicate that GCC should not try to be too clever and simply > leave the specified number of nops before and after the function label, > leaving safety measures to the patching infrastructure.
Yes, please. Consistency is required to maintain a sane stream of instructions for all CPUs involved; this gets particularily nasty on x86 byte code that can in theory cross a cache line boundary with every byte. ARM does not have this problem. Even if it had, it would be a kernel problem, not the compiler's. All that kernel live patching needs is some space to place the patch calls. I currently see the need for 2 NOPs at the beginning of each function; making that configurable would be a plus; leaving additional configurable space before the entry point would be even more flexible. Fentry, like ppc64 profile-kernel, does more than necessary by generating a call already. On ppc64 currently, that branch target isn't even actively used, and the first thing the kernel does is patch these calls with NOPs. So why not start with the NOPs right away? An architecture-independent, variable number might stimulate use cases on other OSes and architectures as well. Torsten