[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111006203358.GA5985@redhat.com>
Date: Thu, 6 Oct 2011 16:33:58 -0400
From: Jason Baron <jbaron@...hat.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: "H. Peter Anvin" <hpa@...or.com>,
Jeremy Fitzhardinge <jeremy@...p.org>,
"David S. Miller" <davem@...emloft.net>,
David Daney <david.daney@...ium.com>,
Michael Ellerman <michael@...erman.id.au>,
Jan Glauber <jang@...ux.vnet.ibm.com>,
the arch/x86 maintainers <x86@...nel.org>,
Xen Devel <xen-devel@...ts.xensource.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>,
peterz@...radead.org, rth@...hat.com
Subject: Re: [PATCH RFC V2 3/5] jump_label: if a key has already been
initialized, don't nop it out
On Thu, Oct 06, 2011 at 03:34:13PM -0400, Steven Rostedt wrote:
> On Thu, 2011-10-06 at 14:38 -0400, Jason Baron wrote:
>
> > Right, its certainly doable, but I'm not sure its so simple, since we'll
> > need a pass to eliminate the jumps - which can be keyed off the
> > '__jump_table' section.
>
> Look at the code of scripts/recordmcount.c and friends.
>
> It does two things.
>
> 1) find all the callers of mcount and make a section for it.
>
> 2) For those callers of mcount that is in sections that are not
> whitelisted, and therefor will not be patched, to replace the call to
> mcount with a nop.
>
>
> We can use this code, or a copy of it, to do the same with jump_label.
> Have the x86 jump_label be:
>
>
> static __always_inline bool arch_static_branch(struct jump_label_key
> *key)
> {
> asm goto("1:"
> "jmp l_yes\n"
> ".pushsection __jump_table, \"aw\" \n\t"
> _ASM_ALIGN "\n\t"
> _ASM_PTR "1b, %l[l_yes], %c0 \n\t"
> ".popsection \n\t"
> : : "i" (key) : : l_yes);
> return false;
> l_yes:
> return true;
> }
>
> Then have the record_jumplabel.c (or whatever it's called) find all the
> jmps at run time, and convert them into the appropriate nop.
>
I'd prefer to do this at build-time as hpa said. We don't want there to
be some race b/w patching in the no-ops and taking an incorrect branch.
> Then at runtime patching, the jumplabel code could figure out what size
> jump it needs to replace it.
>
> -- Steve
>
>
sounds like a good plan. thanks for the pointers!
-Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists