On Fri, Jul 08, 2016 at 05:24:21PM +0200, Petr Mladek wrote: > On Fri 2016-07-08 17:07:09, Torsten Duwe wrote: > > On Fri, Jul 08, 2016 at 04:58:00PM +0200, Petr Mladek wrote: > > > On Mon 2016-06-27 17:17:17, Torsten Duwe wrote: > > > > Once gcc is enhanced to optionally generate NOPs at the beginning > > > > of each function, like the concept proven in > > > > https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01671.html > > > > (sans the "fprintf (... pad_size);", which spoils the data structure > > > > for kernel use), the generated pads can nicely be used to reroute > > > > function calls for tracing/profiling, or live patching. > > > > diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c > > > > index ebecf9a..917065c 100644 > > > > --- a/arch/arm64/kernel/ftrace.c > > > > +++ b/arch/arm64/kernel/ftrace.c > > > > @@ -39,6 +39,12 @@ static int ftrace_modify_code(unsigned long pc, u32 old, u32 new, > > > > if (aarch64_insn_read((void *)pc, &replaced)) > > > > return -EFAULT; > > > > > > > > + /* If we already have what we'll finally want, > > > > + * report success. This is needed on startup. > > > > + */ > > > > + if (replaced == new) > > > > + return 0; > > > > > > This looks strange. I wonder if it actually hides a real bug that we > > > modify the code twice or so. > > > > Not at all. All "profilers" we abused so far generate code that needs to > > be disabled on boot first. prolog-pad generates nops, initially. > > Yeah, but I cannot find this kind of check in other architectures. > I checked arch/x86/kernel/ftrace.c, arch/s390/kernel/ftrace.c, and > arch/powerpc/kernel/ftrace.c. These all support ftrace with > regs and livepatching. My understanding is that other arches don't need this check because they use -mfentry, so they have to modify the "call fentry" instruction to a nop on startup. Here, with -fprolog-pad, it's already a nop, so no change is needed. -- Josh -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
