08 Apr, 2016

2 commits

  • The --page-offset command line option was only used for ARM, to filter
    symbol addresses below CONFIG_PAGE_OFFSET. This is no longer needed, so
    remove the functionality altogether.

    Acked-by: Nicolas Pitre
    Acked-by: Chris Brandt
    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Russell King

    Ard Biesheuvel
     
  • On ARM, the linker may emit veneers to deal with relative branch
    instructions that appear too far away from their targets. Since the
    second kallsyms pass results in an increase of the kernel size, it may
    result in additional veneers to be emitted, potentially affecting the
    output of kallsyms itself if these symbols are visible to it, and for
    that reason, symbols whose names end in '_veneer' are ignored explicitly.

    However, when building Thumb2 kernels, such veneers are named differently
    if they also incur a mode switch, and since they are not filtered by
    kallsyms, they may cause the build to fail. So filter symbols whose names
    end in '_from_arm' or '_from_thumb' as well.

    Tested-by: Arnd Bergmann
    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Russell King

    Ard Biesheuvel
     

16 Mar, 2016

2 commits

  • Similar to how relative extables are implemented, it is possible to emit
    the kallsyms table in such a way that it contains offsets relative to
    some anchor point in the kernel image rather than absolute addresses.

    On 64-bit architectures, it cuts the size of the kallsyms address table
    in half, since offsets between kernel symbols can typically be expressed
    in 32 bits. This saves several hundreds of kilobytes of permanent
    .rodata on average. In addition, the kallsyms address table is no
    longer subject to dynamic relocation when CONFIG_RELOCATABLE is in
    effect, so the relocation work done after decompression now doesn't have
    to do relocation updates for all these values. This saves up to 24
    bytes (i.e., the size of a ELF64 RELA relocation table entry) per value,
    which easily adds up to a couple of megabytes of uncompressed __init
    data on ppc64 or arm64. Even if these relocation entries typically
    compress well, the combined size reduction of 2.8 MB uncompressed for a
    ppc64_defconfig build (of which 2.4 MB is __init data) results in a ~500
    KB space saving in the compressed image.

    Since it is useful for some architectures (like x86) to retain the
    ability to emit absolute values as well, this patch also adds support
    for capturing both absolute and relative values when
    KALLSYMS_ABSOLUTE_PERCPU is in effect, by emitting absolute per-cpu
    addresses as positive 32-bit values, and addresses relative to the
    lowest encountered relative symbol as negative values, which are
    subtracted from the runtime address of this base symbol to produce the
    actual address.

    Support for the above is enabled by default for all architectures except
    IA-64 and Tile-GX, whose symbols are too far apart to capture in this
    manner.

    Signed-off-by: Ard Biesheuvel
    Tested-by: Guenter Roeck
    Reviewed-by: Kees Cook
    Tested-by: Kees Cook
    Cc: Heiko Carstens
    Cc: Michael Ellerman
    Cc: Ingo Molnar
    Cc: H. Peter Anvin
    Cc: Benjamin Herrenschmidt
    Cc: Michal Marek
    Cc: Rusty Russell
    Cc: Arnd Bergmann
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ard Biesheuvel
     
  • Commit c6bda7c988a5 ("kallsyms: fix percpu vars on x86-64 with
    relocation") overloaded the 'A' (absolute) symbol type to signify that a
    symbol is not subject to dynamic relocation. However, the original A
    type does not imply that at all, and depending on the version of the
    toolchain, many A type symbols are emitted that are in fact relative to
    the kernel text, i.e., if the kernel is relocated at runtime, these
    symbols should be updated as well.

    For instance, on sparc32, the following symbols are emitted as absolute
    (kindly provided by Guenter Roeck):

    f035a420 A _etext
    f03d9000 A _sdata
    f03de8c4 A jiffies
    f03f8860 A _edata
    f03fc000 A __init_begin
    f041bdc8 A __init_text_end
    f0423000 A __bss_start
    f0423000 A __init_end
    f044457d A __bss_stop
    f044457d A _end

    On x86_64, similar behavior can be observed:

    ffffffff81a00000 A __end_rodata_hpage_align
    ffffffff81b19000 A __vvar_page
    ffffffff81d3d000 A _end

    Even if only a couple of them pass the symbol range check that results
    in them to be taken into account for the final kallsyms symbol table, it
    is obvious that 'A' does not mean the symbol does not need to be updated
    at relocation time, and overloading its meaning to signify that is
    perhaps not a good idea.

    So instead, add a new percpu_absolute member to struct sym_entry, and
    when --absolute-percpu is in effect, use it to record symbols whose
    addresses should be emitted as final values rather than values that
    still require relocation at runtime. That way, we can drop the check
    against the 'A' type.

    Signed-off-by: Ard Biesheuvel
    Tested-by: Guenter Roeck
    Reviewed-by: Kees Cook
    Tested-by: Kees Cook
    Cc: Heiko Carstens
    Cc: Michael Ellerman
    Cc: Ingo Molnar
    Cc: H. Peter Anvin
    Cc: Benjamin Herrenschmidt
    Cc: Michal Marek
    Acked-by: Rusty Russell
    Cc: Arnd Bergmann
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ard Biesheuvel
     

07 Apr, 2015

2 commits

  • Since we have required at least GCC v3.2 for some time now, we
    can drop the special handling of the 'gcc[0-9]_compiled.' label
    which is not emitted anymore since GCC v3.0.

    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Michal Marek

    Ard Biesheuvel
     
  • When linking large kernels on ARM, the linker will insert veneers
    (i.e., PLT like stubs) when function symbols are out of reach for
    the ordinary relative branch/branch-and-link instructions.

    However, due to the fact that the kallsyms region sits in .rodata,
    which is between .text and .init.text, additional veneers may be
    emitted in the second pass due to the fact that the size of the
    kallsyms region itself has pushed the .init.text section further
    apart, requiring even more veneers.

    So ignore the veneers when generating the symbol table. Veneers
    have no corresponding source code, and they will not turn up in
    backtraces anyway.

    This patch also lightly refactors the symbol_valid() function
    to use a local 'sym_name' rather than the obfuscated 'sym + 1'
    and 'sym + offset'

    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Michal Marek

    Ard Biesheuvel
     

03 Oct, 2014

1 commit

  • Similar to ARM, AArch64 is generating $x and $d syms... which isn't
    terribly helpful when looking at %pF output and the like. Filter those
    out in kallsyms, modpost and when looking at module symbols.

    Seems simplest since none of these check EM_ARM anyway, to just add it
    to the strchr used, rather than trying to make things overly
    complicated.

    initcall_debug improves:
    dmesg_before.txt: initcall $x+0x0/0x154 [sg] returned 0 after 26331 usecs
    dmesg_after.txt: initcall init_sg+0x0/0x154 [sg] returned 0 after 15461 usecs

    Signed-off-by: Kyle McMartin
    Acked-by: Rusty Russell
    Signed-off-by: Catalin Marinas

    Kyle McMartin
     

10 Jun, 2014

1 commit


17 Mar, 2014

2 commits

  • x86-64 has a problem: per-cpu variables are actually represented by
    their absolute offsets within the per-cpu area, but the symbols are
    not emitted as absolute. Thus kallsyms naively creates them as offsets
    from _text, meaning their values change if the kernel is relocated
    (especially noticeable with CONFIG_RANDOMIZE_BASE):

    $ egrep ' (gdt_|_(stext|_per_cpu_))' /root/kallsyms.nokaslr
    0000000000000000 D __per_cpu_start
    0000000000004000 D gdt_page
    0000000000014280 D __per_cpu_end
    ffffffff810001c8 T _stext
    ffffffff81ee53c0 D __per_cpu_offset
    $ egrep ' (gdt_|_(stext|_per_cpu_))' /root/kallsyms.kaslr1
    000000001f200000 D __per_cpu_start
    000000001f204000 D gdt_page
    000000001f214280 D __per_cpu_end
    ffffffffa02001c8 T _stext
    ffffffffa10e53c0 D __per_cpu_offset

    Making them absolute symbols is the Right Thing, but requires fixes to
    the relocs tool. So for the moment, we add a --absolute-percpu option
    which makes them absolute from a kallsyms perspective:

    $ egrep ' (gdt_|_(stext|_per_cpu_))' /proc/kallsyms # no KASLR
    0000000000000000 A __per_cpu_start
    000000000000a000 A gdt_page
    0000000000013040 A __per_cpu_end
    ffffffff802001c8 T _stext
    ffffffff8099b180 D __per_cpu_offset
    ffffffff809a3000 D __per_cpu_load
    $ egrep ' (gdt_|_(stext|_per_cpu_))' /proc/kallsyms # With KASLR
    0000000000000000 A __per_cpu_start
    000000000000a000 A gdt_page
    0000000000013040 A __per_cpu_end
    ffffffff89c001c8 T _stext
    ffffffff8a39d180 D __per_cpu_offset
    ffffffff8a3a5000 D __per_cpu_load

    Based-on-the-original-screenplay-by: Andy Honig
    Signed-off-by: Rusty Russell
    Acked-by: Kees Cook

    Rusty Russell
     
  • This refactors the address range checks to be generalized instead of
    specific to text range checks, in preparation for other range checks.
    Also extracts logic for "is the symbol absolute" into a function.

    Signed-off-by: Kees Cook
    Signed-off-by: Rusty Russell

    Kees Cook
     

11 Mar, 2014

1 commit

  • Revert the recently applied 0f55159d091c ("kallsyms: fix absolute
    addresses for kASLR"). Kees said

    : This got NAKed, please don't apply -- this patch works for x86 and
    : ARM, but may cause problems for others:
    :
    : https://lkml.org/lkml/2014/2/24/718

    It appears that Kees will be fixing all this up for 3.15.

    Cc: Andy Honig
    Cc: Kees Cook
    Cc: Michal Marek
    Cc: Rusty Russell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

04 Mar, 2014

1 commit

  • Currently symbols that are absolute addresses are incorrectly displayed
    in /proc/kallsyms if the kernel is loaded with kASLR.

    The problem was that the scripts/kallsyms.c file which generates the
    array of symbol names and addresses uses an relocatable value for all
    symbols, even absolute symbols. This patch fixes that.

    Several kallsyms output in different boot states for comparison:

    $ egrep '_(stext|_per_cpu_(start|end))' /root/kallsyms.nokaslr
    0000000000000000 D __per_cpu_start
    0000000000014280 D __per_cpu_end
    ffffffff810001c8 T _stext
    $ egrep '_(stext|_per_cpu_(start|end))' /root/kallsyms.kaslr1
    000000001f200000 D __per_cpu_start
    000000001f214280 D __per_cpu_end
    ffffffffa02001c8 T _stext
    $ egrep '_(stext|_per_cpu_(start|end))' /root/kallsyms.kaslr2
    000000000d400000 D __per_cpu_start
    000000000d414280 D __per_cpu_end
    ffffffff8e4001c8 T _stext
    $ egrep '_(stext|_per_cpu_(start|end))' /root/kallsyms.kaslr-fixed
    0000000000000000 D __per_cpu_start
    0000000000014280 D __per_cpu_end
    ffffffffadc001c8 T _stext

    Signed-off-by: Andy Honig
    Signed-off-by: Kees Cook
    Cc: Michal Marek
    Cc: Rusty Russell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andy Honig
     

16 Nov, 2013

1 commit

  • Pull kbuild changes from Michal Marek:
    - LTO fixes, but the kallsyms part had to be reverted
    - Pass -Werror=implicit-int and -Werror=strict-prototypes to the
    compiler by default
    - snprintf fix in modpost
    - remove GREP_OPTIONS from the environment to be immune against exotic
    grep option settings

    * 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
    kallsyms: Revert back to 128 max symbol length
    Kbuild: Ignore GREP_OPTIONS env variable
    scripts: kallsyms: Use %zu to print 'size_t'
    scripts/bloat-o-meter: use .startswith rather than fragile slicing
    scripts/bloat-o-meter: ignore changes in the size of linux_banner
    kbuild: replace unbounded sprintf call in modpost
    kbuild, bloat-o-meter: fix static detection
    Kbuild: Handle longer symbols in kallsyms.c
    kbuild: Increase kallsyms max symbol length
    Makefile: enable -Werror=implicit-int and -Werror=strict-prototypes by default

    Linus Torvalds
     

13 Nov, 2013

1 commit

  • This reverts commits
    f3462aa (Kbuild: Handle longer symbols in kallsyms.c) and
    eea0e9c (kbuild: Increase kallsyms max symbol length)
    except for the added overflow check. The reason is a regression caused
    by increasing the buffer:
    http://marc.info/?l=linux-kernel&m=138387700415675.

    Reported-by: Fengguang Wu
    Cc: Andi Kleen
    Cc: Joe Mario
    Signed-off-by: Michal Marek

    Michal Marek
     

08 Nov, 2013

1 commit

  • Commit f3462aa95 (Kbuild: Handle longer symbols in kallsyms.c) introduced the
    following warning on ARM:

    scripts/kallsyms.c:121:4: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'size_t' [-Wformat]

    Use %zu to print 'size_t'.

    Signed-off-by: Fabio Estevam
    Signed-off-by: Michal Marek

    Fabio Estevam
     

07 Nov, 2013

1 commit


02 Nov, 2013

1 commit

  • This patch uses CONFIG_PAGE_OFFSET to filter symbols which
    are not in kernel address space because these symbols are
    generally for generating code purpose and can't be run at
    kernel mode, so we needn't keep them in /proc/kallsyms.

    For example, on ARM there are some symbols which may be
    linked in relocatable code section, then perf can't parse
    symbols any more from /proc/kallsyms, this patch fixes the
    problem (introduced b9b32bf70f2fb710b07c94e13afbc729afe221da)

    Cc: Russell King
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: Michal Marek
    Signed-off-by: Ming Lei
    Signed-off-by: Rusty Russell
    Cc: stable@vger.kernel.org

    Ming Lei
     

12 May, 2011

1 commit

  • Description:
    This bug hardly appears during real kernel compiling,
    because the vmlinux symbols table is huge.

    But we can still catch it under strict condition , as follows.
    $ echo "c101b97b T do_fork" | ./scripts/kallsyms --all-symbols
    #include
    ......
    ......
    .globl kallsyms_token_table
    ALGN
    kallsyms_token_table:
    Segmentation fault (core dumped)
    $

    If symbols table is small, all entries in token_profit[0x10000] may
    decrease to 0 after several calls of compress_symbols() in optimize_result().
    In that case, find_best_token() always return 0 and
    best_table[i] is set to "\0\0" and best_table_len[i] is set to 2.

    As a result, expand_symbol(best_table[0]="\0\0", best_table_len[0]=2, buf)
    in write_src() will run in infinite recursion until stack overflows,
    causing segfault.

    This patch checks the find_best_token() return value. If all entries in
    token_profit[0x10000] become 0 according to return value, it breaks the loop
    in optimize_result().
    And expand_symbol() works well when best_table_len[i] is 0.

    Signed-off-by: Xiaochen Wang
    Acked-by: Paulo Marques
    Signed-off-by: Michal Marek

    Xiaochen Wang
     

29 Sep, 2010

1 commit


02 Feb, 2010

1 commit

  • Suppress a warn_unused_result warning.

    fgets is called as a part of error handling. It is called just to drop a
    line and return immediately. read_map is reading the file in a loop and
    read_symbol reads line by line. So I think there is no point in using
    return value for useful checking. Other checks like 3 items were returned
    or !EOF have already been done.

    Signed-off-by: Himanshu Chauhan
    Cc: WANG Cong
    Cc: Michal Marek
    Signed-off-by: Andrew Morton
    Signed-off-by: Michal Marek

    Himanshu Chauhan
     

23 Sep, 2009

1 commit

  • Commit b478b782e110fdb4135caa3062b6d687e989d994 "kallsyms, tracing: output
    more proper symbol name" introduces a "bugfix" that introduces a segfault
    in kallsyms in my configurations.

    The cause is the introduction of prefix_underscores_count() which attempts
    to count underscores, even in symbols that do not have them. As a result,
    it just uselessly runs past the end of the buffer until it crashes:

    CC init/version.o
    LD init/built-in.o
    LD .tmp_vmlinux1
    KSYM .tmp_kallsyms1.S
    /bin/sh: line 1: 16934 Done sh-linux-gnu-nm -n .tmp_vmlinux1
    16935 Segmentation fault | scripts/kallsyms > .tmp_kallsyms1.S
    make: *** [.tmp_kallsyms1.S] Error 139

    This simplifies the logic and just does a straightforward count.

    Signed-off-by: Paul Mundt
    Reviewed-by: Li Zefan
    Cc: Lai Jiangshan
    Cc: Sam Ravnborg
    Cc: Paulo Marques
    Cc: Ingo Molnar
    Cc: [2.6.30.x, 2.6.31.x]
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul Mundt
     

20 Jun, 2009

1 commit


15 Jun, 2009

2 commits


14 Mar, 2009

1 commit

  • Impact: bugfix, output more reliable symbol lookup result

    Debug tools(dump_stack(), ftrace...) are like to print out symbols.
    But it is always print out the first aliased symbol.(Aliased symbols
    are symbols with the same address), and the first aliased symbol is
    sometime not proper.

    # echo function_graph > current_tracer
    # cat trace
    ......
    1) 1.923 us | select_nohz_load_balancer();
    1) + 76.692 us | }
    1) | default_idle() {
    1) ==========> | __irqentry_text_start() {
    1) 0.000 us | native_apic_mem_write();
    1) | irq_enter() {
    1) 0.000 us | idle_cpu();
    1) | tick_check_idle() {
    1) 0.000 us | tick_check_oneshot_broadcast();
    1) | tick_nohz_stop_idle() {
    ......

    It's very embarrassing, it ouputs "__irqentry_text_start()",
    actually, it should output "smp_apic_timer_interrupt()".
    (these two symbol are the same address, but "__irqentry_text_start"
    is deemed to the first aliased symbol by scripts/kallsyms)

    This patch puts symbols like "__irqentry_text_start" to the second
    aliased symbols. And a more proper symbol name becomes the first.

    Aliased symbols mostly come from linker script. The solution is
    guessing "is this symbol defined in linker script", the symbols
    defined in linker script will not become the first aliased symbol.

    And if symbols are found to be equal in this "linker script provided"
    criteria, symbols are sorted by the number of prefix underscores.

    Signed-off-by: Lai Jiangshan
    Acked-by: Sam Ravnborg
    Reviewed-by: Paulo Marques
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Lai Jiangshan
     

15 Jan, 2009

1 commit

  • This reverts commit ad7a953c522ceb496611d127e51e278bfe0ff483.

    And commit: ("allow stripping of generated symbols under CONFIG_KALLSYMS_ALL")
    9bb482476c6c9d1ae033306440c51ceac93ea80c

    These stripping patches has caused a set of issues:

    1) People have reported compatibility issues with binutils due to
    lack of support for `--strip-unneeded-symbols' with objcopy 2.15.92.0.2
    Reported by: Wenji
    2) ccache and distcc no longer works as expeced
    Reported by: Ted, Roland, + others
    3) The installed modules increased a lot in size
    Reported by: Ted, Davej + others

    Reported-by: Wenji Huang
    Reported-by: "Theodore Ts'o"
    Reported-by: Dave Jones
    Reported-by: Roland McGrath
    Signed-off-by: Sam Ravnborg

    Sam Ravnborg
     

20 Dec, 2008

1 commit

  • Building upon parts of the module stripping patch, this patch
    introduces similar stripping for vmlinux when CONFIG_KALLSYMS_ALL=y.
    Using CONFIG_KALLSYMS_STRIP_GENERATED reduces the overhead of
    CONFIG_KALLSYMS_ALL from 245k/310k to 65k/80k for the (i386/x86-64)
    kernels I tested with.

    The patch also does away with the need to special case the kallsyms-
    internal symbols by making them available even in the first linking
    stage.

    While it is a generated file, the patch includes the changes to
    scripts/genksyms/keywords.c_shipped, as I'm unsure what the procedure
    here is.

    Signed-off-by: Jan Beulich
    Signed-off-by: Sam Ravnborg

    Jan Beulich
     

20 May, 2008

1 commit

  • Andi Kleen
    reported that he saw a lot of symbols like this:

    0000000000000b24 N DW.aio.h.903a6d92.2
    0000000000000bce N DW.task_io_accounting.h.8d8de327.0
    0000000000000bec N DW.hrtimer.h.c23659c6.0

    in his System.map / kallsyms output.

    Simple solution is to skip all debugging
    symbols (they are marked 'N').

    Signed-off-by: Sam Ravnborg
    Cc: Paulo Marques

    Sam Ravnborg
     

30 Apr, 2008

1 commit

  • Pointed out by Paulo:
    "When I wrote this initially, it was a mistake to add a Changelog in
    the first place, but I didn't know better at the time.

    If you're going to make changes to this file, please remove all the
    Changelog, instead of adding more entries to it. The 'Changelog'
    should be kept by the version control system, and not the source code
    itself."

    Cc: Paulo Marques
    Signed-off-by: Bryan Wu
    Acked-by: Paulo Marques
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bryan Wu
     

07 Feb, 2008

2 commits

  • When resolving symbol names from addresses with aliased symbol names,
    kallsyms_lookup always returns the first symbol, even if it is a weak
    symbol.

    This patch changes this by sorting the symbols with the weak symbols last
    before feeding them to the kernel. This way the kernel runtime isn't
    changed at all, only the kallsyms build system is changed.

    Another side effect is that the symbols get sorted by address, too. So,
    even if future binutils version have some bug in "nm" that makes it fail to
    correctly sort symbols by address, the kernel won't be affected by this.

    Mathieu says:

    I created a module in LTTng that uses kallsyms to get the symbol
    corresponding to a specific system call address. Unfortunately, all the
    unimplemented syscalls were all referring to the (same) weak symbol
    identifying an unrelated system call rather that sys_ni (or whatever
    non-weak symbol would be expected). Kallsyms was dumbly returning the first
    symbol that matched.

    This patch makes sure kallsyms returns the non-weak symbol when there is
    one, which seems to be the expected result.

    [akpm@linux-foundation.org: coding-style fixes]
    Signed-off-by: Mathieu Desnoyers
    Looks-great-to: Rusty Russell
    Cc: Sam Ravnborg
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paulo Marques
     
  • When passing a zero address to kallsyms_lookup(), the kernel thought it was
    a valid kernel address, even if it is not. This is because is_ksym_addr()
    called is_kernel_extratext() and checked against labels that don't exist on
    many archs (which default as zero). Since PPC was the only kernel which
    defines _extra_text, (in 2005), and no longer needs it, this patch removes
    _extra_text support.

    For some history (provided by Jon):
    http://ozlabs.org/pipermail/linuxppc-dev/2005-September/019734.html
    http://ozlabs.org/pipermail/linuxppc-dev/2005-September/019736.html
    http://ozlabs.org/pipermail/linuxppc-dev/2005-September/019751.html

    [akpm@linux-foundation.org: coding-style fixes]
    Signed-off-by: Robin Getz
    Cc: David Woodhouse
    Cc: Jon Loeliger
    Cc: Paul Mackerras
    Cc: Benjamin Herrenschmidt
    Cc: Sam Ravnborg
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Robin Getz
     

20 Jul, 2007

1 commit

  • * git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild: (33 commits)
    xtensa: use DATA_DATA in xtensa
    powerpc: add missing DATA_DATA to powerpc
    cris: use DATA_DATA in cris
    kallsyms: remove usage of memmem and _GNU_SOURCE from scripts/kallsyms.c
    kbuild: use -fno-optimize-sibling-calls unconditionally
    kconfig: reset generated values only if Kconfig and .config agree.
    kbuild: fix the warning when running make tags
    kconfig: strip 'CONFIG_' automatically in kernel configuration search
    kbuild: use POSIX BRE in headers install target
    Whitelist references from __dbe_table to .init
    modpost white list pattern adjustment
    kbuild: do section mismatch check on full vmlinux
    kbuild: whitelist references from variables named _timer to .init.text
    kbuild: remove hardcoded _logo names from modpost
    kbuild: remove hardcoded apic_es7000 from modpost
    kbuild: warn about references from .init.text to .exit.text
    kbuild: consolidate section checks
    kbuild: refactor code in modpost to improve maintainability
    kbuild: ignore section mismatch warnings originating from .note section
    kbuild: .paravirtprobe section is obsolete, so modpost doesn't need to handle it
    ...

    Linus Torvalds
     

18 Jul, 2007

1 commit

  • KSYM_NAME_LEN is peculiar in that it does not include the space for the
    trailing '\0', forcing all users to use KSYM_NAME_LEN + 1 when allocating
    buffer. This is nonsense and error-prone. Moreover, when the caller
    forgets that it's very likely to subtly bite back by corrupting the stack
    because the last position of the buffer is always cleared to zero.

    This patch increments KSYM_NAME_LEN by one and updates code accordingly.

    * off-by-one bug in asm-powerpc/kprobes.h::kprobe_lookup_name() macro
    is fixed.

    * Where MODULE_NAME_LEN and KSYM_NAME_LEN were used together,
    MODULE_NAME_LEN was treated as if it didn't include space for the
    trailing '\0'. Fix it.

    Signed-off-by: Tejun Heo
    Acked-by: Paulo Marques
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mackerras
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tejun Heo
     

17 Jul, 2007

1 commit


09 Dec, 2006

1 commit


07 Dec, 2006

2 commits

  • o On some platforms like avr32, section init comes before .text and
    not necessarily a symbol's relative position w.r.t _text is positive.
    In such cases assembler detects the overflow and emits warning. This
    patch fixes it.

    Signed-off-by: Vivek Goyal
    Signed-off-by: Andi Kleen
    Cc: Andi Kleen
    Cc: Haavard Skinnemoen
    Signed-off-by: Andrew Morton

    Vivek Goyal
     
  • Print the addresses of non-absolute symbols relative to _text
    so that ld will generate relocations. Allowing a relocatable
    kernel to relocate them. We can't actually use the symbol names
    because kallsyms includes static symbols that are not exported
    from their object files.

    Add the _text symbol definitions to the architectures which don't
    define it otherwise linker will fail.

    Signed-off-by: Eric W. Biederman
    Signed-off-by: Vivek Goyal
    Signed-off-by: Andi Kleen

    Eric W. Biederman
     

26 Mar, 2006

1 commit


08 Sep, 2005

2 commits

  • Local symbols generated by gcc start with a `$'; no point in including them
    in the kernel.

    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ralf Baechle
     
  • This patch changes the way the compression algorithm works. The base
    algorithm is similiar to the previous but we force the compressed token
    size to 2.

    Having a fixed size compressed token allows for a lot of optimizations, and
    that in turn allows this code to run over *all* the symbols faster than it
    did before over just a subset.

    Having it work over all the symbols will make it behave better when symbols
    change positions between passes, and the "inconsistent kallsyms" messages
    should become less frequent.

    In my tests the compression ratio was degraded by about 0.5%, but the
    results will depend greatly on the number of symbols to compress.

    Signed-off-by: Paulo Marques
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paulo Marques