WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH][RFC] jump_labels/x86: Use either 5 byte or 2 byt

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: [Xen-devel] Re: [PATCH][RFC] jump_labels/x86: Use either 5 byte or 2 byte jumps
From: Steven Rostedt <rostedt@xxxxxxxxxxx>
Date: Fri, 07 Oct 2011 15:58:20 -0400
Cc: arch/x86 maintainers <x86@xxxxxxxxxx>, Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>, David Daney <david.daney@xxxxxxxxxx>, peterz@xxxxxxxxxxxxx, Jason Baron <jbaron@xxxxxxxxxx>, Jan Glauber <jang@xxxxxxxxxxxxxxxxxx>, Richard Henderson <rth@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Michael Ellerman <michael@xxxxxxxxxxxxxx>, Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, the, "David S. Miller" <davem@xxxxxxxxxxxxx>
Delivery-date: Fri, 07 Oct 2011 13:05:25 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E8F55B7.9010409@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <cover.1317506051.git.jeremy.fitzhardinge@xxxxxxxxxx> <477dead9647029012f93c651f2892ed0e86b89e7.1317506051.git.jeremy.fitzhardinge@xxxxxxxxxx> <20111003150205.GB2462@xxxxxxxxxx> <4E89E28C.7010700@xxxxxxxx> <20111004141011.GA2520@xxxxxxxxxx> <4E8B3489.60902@xxxxxxxxx> <4E8CF348.4080405@xxxxxxxx> <4E8CF385.2080804@xxxxxxxxx> <4E8DEB19.1050509@xxxxxxxx> <20111006181055.GA2505@xxxxxxxxxx> <1317925615.4729.14.camel@xxxxxxxxxxxxxxxxxxx> <4E8DF870.6010000@xxxxxxxxxx> <1317929321.4729.17.camel@xxxxxxxxxxxxxxxxxxx> <4E8E20CD.5030207@xxxxxxxx> <1317938775.4729.29.camel@xxxxxxxxxxxxxxxxxxx> <4E8E275F.6010801@xxxxxxxx> <1318007374.4729.58.camel@xxxxxxxxxxxxxxxxxxx> <4E8F55B7.9010409@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Fri, 2011-10-07 at 12:40 -0700, Jeremy Fitzhardinge wrote:
> On 10/07/2011 10:09 AM, Steven Rostedt wrote:
> > diff --git a/arch/x86/kernel/jump_label.c b/arch/x86/kernel/jump_label.c
> > index 3fee346..1f7f88f 100644
> > --- a/arch/x86/kernel/jump_label.c
> > +++ b/arch/x86/kernel/jump_label.c
> > @@ -16,34 +16,75 @@
> >  
> >  #ifdef HAVE_JUMP_LABEL
> >  
> > +static unsigned char nop_short[] = { P6_NOP2 };
> > +
> >  union jump_code_union {
> >     char code[JUMP_LABEL_NOP_SIZE];
> >     struct {
> >             char jump;
> >             int offset;
> >     } __attribute__((packed));
> > +   struct {
> > +           char jump_short;
> > +           char offset_short;
> > +   } __attribute__((packed));
> >  };
> >  
> >  void arch_jump_label_transform(struct jump_entry *entry,
> >                            enum jump_label_type type)
> >  {
> >     union jump_code_union code;
> > +   unsigned char op;
> > +   unsigned size;
> > +   unsigned char nop;
> > +
> > +   /* Use probe_kernel_read()? */
> > +   op = *(unsigned char *)entry->code;
> > +   nop = ideal_nops[NOP_ATOMIC5][0];
> >  
> >     if (type == JUMP_LABEL_ENABLE) {
> > -           code.jump = 0xe9;
> > -           code.offset = entry->target -
> > -                           (entry->code + JUMP_LABEL_NOP_SIZE);
> > -   } else
> > -           memcpy(&code, ideal_nops[NOP_ATOMIC5], JUMP_LABEL_NOP_SIZE);
> > +           if (op == 0xe9 || op == 0xeb)
> > +                   /* Already enabled. Warn? */
> > +                   return;
> > +
> > +           /* FIXME for all archs */
> 
> By "archs", do you mean different x86 variants?

Yeah, that was a confusing use of archs. This was to make sure it works
for all nops for different variants of x86.

> 
> > +           if (op == nop_short[0]) {
> 
> My gut feeling is that all this "trying to determine the jump size by
> sniffing the instruction" stuff seems pretty fragile.  Couldn't you
> store the jump size in the jump_label structure (even as a bit hidden
> away somewhere)?

We could but it's not as fragile as you think. This is machine code, and
it should be a jump or not. I could add more checks, that is, to look at
the full nop to make sure it is truly a nop. But for the jump side, a
byte instruction that starts with e9 is definitely a jump.

I could harden this more like what we do with mcount updates in the
function tracer. I actually calculate what I expect to be there before
looking at what is there. The entire instruction is checked. If it does
not match, then we fail and give big warnings about it.

Other than that, it should be quite solid. If we don't get a match, we
should warn and disable jump labels.

No BUG()!

-- Steve



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>