1. 07 4月, 2015 2 次提交
  2. 03 10月, 2014 1 次提交
    • K
      aarch64: filter $x from kallsyms · 6c34f1f5
      Kyle McMartin 提交于
      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: NKyle McMartin <kyle@redhat.com>
      Acked-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      6c34f1f5
  3. 10 6月, 2014 1 次提交
  4. 17 3月, 2014 2 次提交
    • R
      kallsyms: fix percpu vars on x86-64 with relocation. · c6bda7c9
      Rusty Russell 提交于
      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: NAndy Honig <ahonig@google.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Acked-by: NKees Cook <keescook@chromium.org>
      c6bda7c9
    • K
      kallsyms: generalize address range checking · 78eb7159
      Kees Cook 提交于
      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: NKees Cook <keescook@chromium.org>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      78eb7159
  5. 11 3月, 2014 1 次提交
  6. 04 3月, 2014 1 次提交
    • A
      kallsyms: fix absolute addresses for kASLR · 0f55159d
      Andy Honig 提交于
      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: NAndy Honig <ahonig@google.com>
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0f55159d
  7. 13 11月, 2013 1 次提交
  8. 08 11月, 2013 1 次提交
  9. 07 11月, 2013 1 次提交
  10. 02 11月, 2013 1 次提交
    • M
      scripts/kallsyms: filter symbols not in kernel address space · f6537f2f
      Ming Lei 提交于
      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 b9b32bf7)
      
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: Michal Marek <mmarek@suse.cz>
      Signed-off-by: NMing Lei <tom.leiming@gmail.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: stable@vger.kernel.org
      f6537f2f
  11. 12 5月, 2011 1 次提交
    • X
      scripts/kallsyms.c: fix potential segfault · e0a04b11
      Xiaochen Wang 提交于
      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 <asm/types.h>
         ......
         ......
         .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: NXiaochen Wang <wangxiaochen0@gmail.com>
      Acked-by: NPaulo Marques <pmarques@grupopie.com>
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      e0a04b11
  12. 29 9月, 2010 1 次提交
  13. 02 2月, 2010 1 次提交
  14. 23 9月, 2009 1 次提交
    • P
      kallsyms: fix segfault in prefix_underscores_count() · a9ece53c
      Paul Mundt 提交于
      Commit b478b782 "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: NPaul Mundt <lethal@linux-sh.org>
      Reviewed-by: NLi Zefan <lizf@cn.fujitsu.com>
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Paulo Marques <pmarques@grupopie.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: <stable@kernel.org>		[2.6.30.x, 2.6.31.x]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a9ece53c
  15. 20 6月, 2009 1 次提交
  16. 15 6月, 2009 2 次提交
  17. 14 3月, 2009 1 次提交
    • L
      kallsyms, tracing: output more proper symbol name · b478b782
      Lai Jiangshan 提交于
      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: NLai Jiangshan <laijs@cn.fujitsu.com>
      Acked-by: NSam Ravnborg <sam@ravnborg.org>
      Reviewed-by: NPaulo Marques <pmarques@grupopie.com>
      LKML-Reference: <49BA06E2.7080807@cn.fujitsu.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b478b782
  18. 15 1月, 2009 1 次提交
  19. 20 12月, 2008 1 次提交
    • J
      allow stripping of generated symbols under CONFIG_KALLSYMS_ALL · 9bb48247
      Jan Beulich 提交于
      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: NJan Beulich <jbeulich@novell.com>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      9bb48247
  20. 20 5月, 2008 1 次提交
    • S
      kbuild: filter away debug symbols from kernel symbols · aab34ac8
      Sam Ravnborg 提交于
      Andi Kleen <andi@firstfloor.org>
      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: NSam Ravnborg <sam@ravnborg.org>
      Cc: Paulo Marques <pmarques@grupopie.com>
      aab34ac8
  21. 30 4月, 2008 1 次提交
  22. 07 2月, 2008 2 次提交
  23. 18 7月, 2007 1 次提交
    • T
      kallsyms: make KSYM_NAME_LEN include space for trailing '\0' · 9281acea
      Tejun Heo 提交于
      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: NTejun Heo <htejun@gmail.com>
      Acked-by: NPaulo Marques <pmarques@grupopie.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9281acea
  24. 17 7月, 2007 1 次提交
  25. 09 12月, 2006 1 次提交
  26. 07 12月, 2006 2 次提交
  27. 26 3月, 2006 1 次提交
  28. 08 9月, 2005 2 次提交
  29. 28 7月, 2005 1 次提交
  30. 06 5月, 2005 1 次提交
  31. 01 5月, 2005 1 次提交
  32. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4