lkml.org 
[lkml]   [2010]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 2/3] jump label: move jump table to r/w section
    * Steven Rostedt (rostedt@goodmis.org) wrote:
    > On Tue, 2010-11-23 at 18:55 -0500, Mathieu Desnoyers wrote:
    > > * Jason Baron (jbaron@redhat.com) wrote:
    > > > Since we writing the jump table it should be be in R/W kernel
    > > > section. Move it to DATA_DATA
    > > >
    > > > Signed-off-by: Jason Baron <jbaron@redhat.com>
    > > > ---
    > > > include/asm-generic/vmlinux.lds.h | 14 ++++----------
    > > > 1 files changed, 4 insertions(+), 10 deletions(-)
    > > >
    > > > diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
    > > > index bd69d79..9ca894d 100644
    > > > --- a/include/asm-generic/vmlinux.lds.h
    > > > +++ b/include/asm-generic/vmlinux.lds.h
    > > > @@ -161,6 +161,10 @@
    > > > VMLINUX_SYMBOL(__start___tracepoints) = .; \
    > > > *(__tracepoints) \
    > > > VMLINUX_SYMBOL(__stop___tracepoints) = .; \
    > > > + . = ALIGN(8); \
    > >
    > > Past churn with various architectures and compiler with tracepoints,
    > > markers and immediate values lead me to hint at the following approach
    > > for jump label structure alignment:
    > >
    > > . = ALIGN(32);
    > >
    > > and to modify jump_label.h to have:
    > >
    > > struct jump_entry {
    > > jump_label_t code;
    > > jump_label_t target;
    > > jump_label_t key;
    > > } __attribute__((aligned(32)));
    > >
    > > Otherwise, the compiler is free to choose on which value it prefers to
    > > align the jump_entry structures, which might not match the address at
    > > which the linker scripts puts the beginning of the jump table.
    > >
    > > In this case, given that we put put the jump label table after the
    > > tracepoint table, we should be already aligned on 32 bytes. But I would
    > > recommend to put the . = ALIGN(32) in the linker script anyway, just for
    > > documentation purpose (and it should not add any padding in this case).
    > >
    > > This is not a problem introduced by this patch, it also applies to the
    > > current jump label code.
    >
    > Agreed, but this change could probably wait for 2.6.38.
    >
    > Also, if this is done, then an it should be wrapped in a
    > #ifdef CONFIG_JUMP_LABEL and only inserted if we are using jump labels.
    > Otherwise we may add a 32 byte hole for nothing. I know it's small, but
    > why waste it if you don't need to.

    The lack of proper alignment did cause nasty hard-to-identify/reproduce
    regressions based on the compiler used, target platform and data layout.
    It's up to you, but I'd be much more comfortable merging this in 2.6.37.

    Thanks,

    Mathieu

    --
    Mathieu Desnoyers
    Operating System Efficiency R&D Consultant
    EfficiOS Inc.
    http://www.efficios.com


    \
     
     \ /
      Last update: 2010-11-24 02:09    [W:0.024 / U:2.424 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site