Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 27 7月, 2014 1 次提交
    • M
      scripts: modpost: fix compilation warning · fcd38ed0
      由 Michal Nazarewicz 提交于 
      The scripts/mod/modpost.c triggers the following warning:

scripts/mod/modpost.c: In function ‘remove_dot’:
scripts/mod/modpost.c:1710:10: warning: ignoring return value of ‘strtoul’, declared with attribute warn_unused_result [-Wunused-result]

The remove_dot function that calls strtoul does not care about the
numeric value of the string that is parsed but only looks for the
end of the numeric sequence.  As such, it's equivalent to just skip
over all digits.
Signed-off-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      fcd38ed0
  3. 13 7月, 2014 1 次提交
  5. 26 6月, 2014 1 次提交
    • A
      recordmcount/MIPS: Fix possible incorrect mcount_loc table entries in modules · 91ad11d7
      由 Alex Smith 提交于 
      On MIPS calls to _mcount in modules generate 2 instructions to load
the _mcount address (and therefore 2 relocations). The mcount_loc
table should only reference the first of these, so the second is
filtered out by checking the relocation offset and ignoring ones that
immediately follow the previous one seen.

However if a module has an _mcount call at offset 0, the second
relocation would not be filtered out due to old_r_offset == 0
being taken to mean that the current relocation is the first one
seen, and both would end up in the mcount_loc table.

This results in ftrace_make_nop() patching both (adjacent)
instructions to branches over the _mcount call sequence like so:

  0xffffffffc08a8000:  04 00 00 10     b       0xffffffffc08a8014
  0xffffffffc08a8004:  04 00 00 10     b       0xffffffffc08a8018
  0xffffffffc08a8008:  2d 08 e0 03     move    at,ra
  ...

The second branch is in the delay slot of the first, which is
defined to be unpredictable - on the platform on which this bug was
encountered, it triggers a reserved instruction exception.

Fix by initializing old_r_offset to ~0 and using that instead of 0
to determine whether the current relocation is the first seen.
Signed-off-by: NAlex Smith <alex.smith@imgtec.com>
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/7098/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      91ad11d7
  7. 24 6月, 2014 1 次提交
  9. 19 6月, 2014 1 次提交
  11. 18 6月, 2014 2 次提交
  13. 11 6月, 2014 1 次提交
    • S
      decode_stacktrace: make stack dump output useful again · dbd1abb2
      由 Sasha Levin 提交于 
      Right now when people try to report issues in the kernel they send stack
dumps to eachother, which looks something like this:

  [    6.906437]  [<ffffffff811f0e90>] ? backtrace_test_irq_callback+0x20/0x20
  [    6.907121]  [<ffffffff84388ce8>] dump_stack+0x52/0x7f
  [    6.907640]  [<ffffffff811f0ec8>] backtrace_regression_test+0x38/0x110
  [    6.908281]  [<ffffffff813596a0>] ? proc_create_data+0xa0/0xd0
  [    6.908870]  [<ffffffff870a8040>] ? proc_modules_init+0x22/0x22
  [    6.909480]  [<ffffffff810020c2>] do_one_initcall+0xc2/0x1e0
  [...]

However, most of the text you get is pure garbage.

The only useful thing above is the function name.  Due to the amount of
different kernel code versions and various configurations being used,
the kernel address and the offset into the function are not really
helpful in determining where the problem actually occured.

Too often the result of someone looking at a stack dump is asking the
person who sent it for a translation for one or more 'addr2line'
translations.  Which slows down the entire process of debugging the
issue (and really annoying).

The decode_stacktrace script is an attempt to make the output more
useful and easy to work with by translating all kernel addresses in the
stack dump into line numbers.  Which means that the stack dump would
look like this:

  [  635.148361]  dump_stack (lib/dump_stack.c:52)
  [  635.149127]  warn_slowpath_common (kernel/panic.c:418)
  [  635.150214]  warn_slowpath_null (kernel/panic.c:453)
  [  635.151031]  _oalloc_pages_slowpath+0x6a/0x7d0
  [  635.152171]  ? zone_watermark_ok (mm/page_alloc.c:1728)
  [  635.152988]  ? get_page_from_freelist (mm/page_alloc.c:1939)
  [  635.154766]  __alloc_pages_nodemask (mm/page_alloc.c:2766)

It's pretty obvious why this is better than the previous stack dump
before.

Usage is pretty simple:

        ./decode_stacktrace.sh [vmlinux] [base path]

Where vmlinux is the vmlinux to extract line numbers from and base path
is the path that points to the root of the build tree, for example:

        ./decode_stacktrace.sh vmlinux /home/sasha/linux/ < input.log > output.log

The stack trace should be piped through it (I, for example, just pipe
the output of the serial console of my KVM test box through it).
Signed-off-by: NSasha Levin <sasha.levin@oracle.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dbd1abb2
  15. 10 6月, 2014 15 次提交
  17. 05 6月, 2014 9 次提交
  19. 29 5月, 2014 1 次提交
    • A
      ftrace: Add arm64 support to recordmcount · af64d2aa
      由 AKASHI Takahiro 提交于 
      Recordmcount utility under scripts is run, after compiling each object,
to find out all the locations of calling _mcount() and put them into
specific seciton named __mcount_loc.
Then linker collects all such information into a table in the kernel image
(between __start_mcount_loc and __stop_mcount_loc) for later use by ftrace.

This patch adds arm64 specific definitions to identify such locations.
There are two types of implementation, C and Perl. On arm64, only C version
is used to build the kernel now that CONFIG_HAVE_C_RECORDMCOUNT is on.
But Perl version is also maintained.

This patch also contains a workaround just in case where a header file,
elf.h, on host machine doesn't have definitions of EM_AARCH64 nor
R_AARCH64_ABS64. Without them, compiling C version of recordmcount will
fail.
Acked-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NAKASHI Takahiro <takahiro.akashi@linaro.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
      af64d2aa
  21. 20 5月, 2014 1 次提交
  23. 15 5月, 2014 1 次提交
    • M
      firmware: Simplify directory creation · 5180d5f4
      由 Michal Marek 提交于 
      When building the firmware blobs, use a simple loop to create
directories in $(objtree), like in Makefile.build. This simplifies the
rules and also makes it possible to set $(objtree) to '.' later. Before
this change, a dependency on $(objtree)/<dir> would be satisfied by
<dir> in $(srctree).

When installing the firmware blobs, call mkdir like in Makefile.modinst.

Cc: David Woodhouse <dwmw2@infradead.org>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NMichal Marek <mmarek@suse.cz>
      5180d5f4
  25. 14 5月, 2014 1 次提交
  27. 05 5月, 2014 1 次提交
  29. 30 4月, 2014 2 次提交
  31. 28 4月, 2014 1 次提交