Re: Jump Label initialization

[Steven Rostedt <rostedt@goodmis.org>]

On Thu, 2011-09-29 at 14:04 +0200, Jan Glauber wrote:
> On Wed, 2011-09-28 at 19:14 -0700, Jeremy Fitzhardinge wrote:
> > Hi all,
> > 
> > I'm trying to use the jump label machinery as part of the pv ticketlock
> > work I'm doing on x86.
> > 
> > The problem I'm having at the moment is that I do my spinlock setup in
> > smp_prepare_boot_cpu(), which happens before jump_label_init() gets
> > called, and so the latter goes and nops out all my enabled jump label key.
> > 
> > I'm experimenting at the moment with a patch to allow
> > jump_label_enable() to be called fairly early, and have that be
> > respected by jump_label_init().  I'm doing this by replacing
> > arch_jump_label_poke_text_early() with
> > arch_jump_label_transform_early(), which shares most of its code with
> > its non-early variant, except that it expects to run in a pre-SMP
> > environment.
> > 
> > Does this seem plausible? (I haven't tested it yet.)
> > 
> > The x86, mips and sparc patches are fairly simple; I forgot to look at
> > powerpc, and I didn't fully investigate s390.
> 
> s390 does not have the early() variant since it didn't need it. On
> pre-SMP we probably don't need stop_machine() so creating
> arch_jump_label_transform_early() by leaving out stop_machine()
> and patching the code directly should be fine.

Also note that stop_machine() may only be needed by a few archs (maybe
only x86).

x86 has a nasty condition if you change code that is being loaded in
another CPUs pipeline, it could cause a GPF. I've been playing with this
on PPC and this does not have that same bug. In fact Benjamin told me
that PPC is fine with modifying instructions on a running system.

I plan on removing the stop_machine() from ftrace for those boxes. I
already have patches made, just need to spiffy them up a bit.

-- Steve