1. 03 Jun, 2016 1 commit
    • Mark Rutland's avatar
      arm64: report CPU number in bad_mode · 8051f4d1
      Mark Rutland authored
      If we take an exception we don't expect (e.g. SError), we report this in
      the bad_mode handler with pr_crit. Depending on the configured log
      level, we may or may not log additional information in functions called
      subsequently. Notably, the messages in dump_stack (including the CPU
      number) are printed with KERN_DEFAULT and may not appear.
      Some exceptions have an IMPLEMENTATION DEFINED ESR_ELx.ISS encoding, and
      knowing the CPU number is crucial to correctly decode them. To ensure
      that this is always possible, we should log the CPU number along with
      the ESR_ELx value, so we are not reliant on subsequent logs or
      additional printk configuration options.
      This patch logs the CPU number in bad_mode such that it is possible for
      a developer to decode these exceptions, provided access to sufficient
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Reported-by: default avatarAl Grant <Al.Grant@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Dave Martin <dave.martin@arm.com>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
  2. 12 Feb, 2016 1 commit
  3. 21 Dec, 2015 3 commits
    • Will Deacon's avatar
      arm64: traps: address fallout from printk -> pr_* conversion · c9cd0ed9
      Will Deacon authored
      Commit ac7b406c ("arm64: Use pr_* instead of printk") was a fairly
      mindless s/printk/pr_*/ change driven by a complaint from checkpatch.
      As is usual with such changes, this has led to some odd behaviour on
        * syslog now picks up the "pr_emerg" line from dump_backtrace, but not
          the actual trace, which leads to a bunch of "kernel:Call trace:"
          lines in the log
        * __{pte,pmd,pgd}_error print at KERN_CRIT, as opposed to KERN_ERR
          which is used by other architectures.
      This patch restores the original printk behaviour for dump_backtrace
      and downgrade the pgtable error macros to KERN_ERR.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
    • AKASHI Takahiro's avatar
      arm64: ftrace: fix a stack tracer's output under function graph tracer · 20380bb3
      AKASHI Takahiro authored
      Function graph tracer modifies a return address (LR) in a stack frame
      to hook a function return. This will result in many useless entries
      (return_to_handler) showing up in
       a) a stack tracer's output
       b) perf call graph (with perf record -g)
       c) dump_backtrace (at panic et al.)
      For example, in case of a),
        $ echo function_graph > /sys/kernel/debug/tracing/current_tracer
        $ echo 1 > /proc/sys/kernel/stack_trace_enabled
        $ cat /sys/kernel/debug/tracing/stack_trace
              Depth    Size   Location    (54 entries)
              -----    ----   --------
        0)     4504      16   gic_raise_softirq+0x28/0x150
        1)     4488      80   smp_cross_call+0x38/0xb8
        2)     4408      48   return_to_handler+0x0/0x40
        3)     4360      32   return_to_handler+0x0/0x40
      In case of b),
        $ echo function_graph > /sys/kernel/debug/tracing/current_tracer
        $ perf record -e mem:XXX:x -ag -- sleep 10
        $ perf report
                        |          |          |--0.22%-- 0x550f8
                        |          |          |          0x10888
                        |          |          |          el0_svc_naked
                        |          |          |          sys_openat
                        |          |          |          return_to_handler
                        |          |          |          return_to_handler
      In case of c),
        $ echo function_graph > /sys/kernel/debug/tracing/current_tracer
        $ echo c > /proc/sysrq-trigger
        Call trace:
        [<ffffffc00044d3ac>] sysrq_handle_crash+0x24/0x30
        [<ffffffc000092250>] return_to_handler+0x0/0x40
        [<ffffffc000092250>] return_to_handler+0x0/0x40
      This patch replaces such entries with real addresses preserved in
      current->ret_stack[] at unwind_frame(). This way, we can cover all
      the cases.
      Reviewed-by: default avatarJungseok Lee <jungseoklee85@gmail.com>
      Signed-off-by: default avatarAKASHI Takahiro <takahiro.akashi@linaro.org>
      [will: fixed minor context changes conflicting with irq stack bits]
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
    • AKASHI Takahiro's avatar
      arm64: pass a task parameter to unwind_frame() · fe13f95b
      AKASHI Takahiro authored
      Function graph tracer modifies a return address (LR) in a stack frame
      to hook a function's return. This will result in many useless entries
      (return_to_handler) showing up in a call stack list.
      We will fix this problem in a later patch ("arm64: ftrace: fix a stack
      tracer's output under function graph tracer"). But since real return
      addresses are saved in ret_stack[] array in struct task_struct,
      unwind functions need to be notified of, in addition to a stack pointer
      address, which task is being traced in order to find out real return
      This patch extends unwind functions' interfaces by adding an extra
      argument of a pointer to task_struct.
      Signed-off-by: default avatarAKASHI Takahiro <takahiro.akashi@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
  4. 08 Dec, 2015 1 commit
  5. 19 Oct, 2015 1 commit
    • Jungseok Lee's avatar
      arm64: Synchronise dump_backtrace() with perf callchain · 9f93f3e9
      Jungseok Lee authored
      Unlike perf callchain relying on walk_stackframe(), dump_backtrace()
      has its own backtrace logic. A major difference between them is the
      moment a symbol is recorded. Perf writes down a symbol *before*
      calling unwind_frame(), but dump_backtrace() prints it out *after*
      unwind_frame(). As a result, the last valid symbol cannot be hooked
      in case of dump_backtrace(). This patch addresses the issue as
      synchronising dump_backtrace() with perf callchain.
      A simple test and its results are as follows:
      - crash trigger
       $ sudo echo c > /proc/sysrq-trigger
      - current status
       Call trace:
       [<fffffe00003dc738>] sysrq_handle_crash+0x24/0x30
       [<fffffe00003dd2ac>] __handle_sysrq+0x128/0x19c
       [<fffffe00003dd730>] write_sysrq_trigger+0x60/0x74
       [<fffffe0000249fc4>] proc_reg_write+0x84/0xc0
       [<fffffe00001f2638>] __vfs_write+0x44/0x104
       [<fffffe00001f2e60>] vfs_write+0x98/0x1a8
       [<fffffe00001f3730>] SyS_write+0x50/0xb0
      - with this change
       Call trace:
       [<fffffe00003dc738>] sysrq_handle_crash+0x24/0x30
       [<fffffe00003dd2ac>] __handle_sysrq+0x128/0x19c
       [<fffffe00003dd730>] write_sysrq_trigger+0x60/0x74
       [<fffffe0000249fc4>] proc_reg_write+0x84/0xc0
       [<fffffe00001f2638>] __vfs_write+0x44/0x104
       [<fffffe00001f2e60>] vfs_write+0x98/0x1a8
       [<fffffe00001f3730>] SyS_write+0x50/0xb0
       [<fffffe00000939ec>] el0_svc_naked+0x20/0x28
      Note that this patch does not cover a case where MMU is disabled. The
      last stack frame of swapper, for example, has PC in a form of physical
      address. Unfortunately, a simple conversion using phys_to_virt() cannot
      cover all scenarios since PC is retrieved from LR - 4, not LR. It is
      a big tradeoff to change both head.S and unwind_frame() for only a few
      of symbols in *.S. Thus, this hunk does not take care of the case.
      Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
      Cc: James Morse <james.morse@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarJungseok Lee <jungseoklee85@gmail.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
  6. 27 Jul, 2015 4 commits
    • Dave P Martin's avatar
      arm64/BUG: Show explicit backtrace for WARNs · a4653228
      Dave P Martin authored
      The generic slowpath WARN implementation prints a backtrace, but
      the report_bug() based implementation does not, opting to print the
      registers instead which is generally not as useful.
      Ideally, report_bug() should be fixed to make the behaviour more
      consistent, but in the meantime this patch generates a backtrace
      directly from the arm64 backend instead so that this functionality
      is not lost with the migration to report_bug().
      As a side-effect, the backtrace will be outside the oops end
      marker, but that's hard to avoid without modifying generic code.
      This patch can go away if report_bug() grows the ability in the
      future to generate a backtrace directly or call an arch hook at the
      appropriate time.
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
    • Dave P Martin's avatar
      arm64/BUG: Use BRK instruction for generic BUG traps · 9fb7410f
      Dave P Martin authored
      Currently, the minimal default BUG() implementation from asm-
      generic is used for arm64.
      This patch uses the BRK software breakpoint instruction to generate
      a trap instead, similarly to most other arches, with the generic
      BUG code generating the dmesg boilerplate.
      This allows bug metadata to be moved to a separate table and
      reduces the amount of inline code at BUG and WARN sites.  This also
      avoids clobbering any registers before they can be dumped.
      To mitigate the size of the bug table further, this patch makes
      use of the existing infrastructure for encoding addresses within
      the bug table as 32-bit offsets instead of absolute pointers.
      (Note that this limits the kernel size to 2GB.)
      Traps are registered at arch_initcall time for aarch64, but BUG
      has minimal real dependencies and it is desirable to be able to
      generate bug splats as early as possible.  This patch redirects
      all debug exceptions caused by BRK directly to bug_handler() until
      the full debug exception support has been initialised.
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
    • Will Deacon's avatar
      arm64: force CONFIG_SMP=y and remove redundant #ifdefs · 4b3dc967
      Will Deacon authored
      Nobody seems to be producing !SMP systems anymore, so this is just
      becoming a source of kernel bugs, particularly if people want to use
      coherent DMA with non-shared pages.
      This patch forces CONFIG_SMP=y for arm64, removing a modest amount of
      code in the process.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
    • Rohit Thapliyal's avatar
      arm64: modify the dump mem for 64 bit addresses · e147ae6d
      Rohit Thapliyal authored
      On 64bit kernel, the dump_mem gives 32 bit addresses
      on the stack dump. This gives unorganized information regarding
      the 64bit values on the stack. Hence, modified to get a complete 64bit memory
      With patch:
      [   93.534801] Process insmod (pid: 1587, stack limit = 0xffffffc976be4058)
      [   93.541441] Stack: (0xffffffc976be7cf0 to 0xffffffc976be8000)
      [   93.547136] 7ce0:                                   ffffffc976be7d00 ffffffc00008163c
      [   93.554898] 7d00: ffffffc976be7d40 ffffffc0000f8a44 ffffffc00098ef38 ffffffbffc000088
      [   93.562659] 7d20: ffffffc00098ef50 ffffffbffc0000c0 0000000000000001 ffffffbffc000070
      [   93.570419] 7d40: ffffffc976be7e40 ffffffc0000f935c 0000000000000000 000000002b424090
      [   93.578179] 7d60: 000000002b424010 0000007facc555f4 0000000080000000 0000000000000015
      [   93.585937] 7d80: 0000000000000116 0000000000000069 ffffffc00097b000 ffffffc976be4000
      [   93.593694] 7da0: 0000000000000064 0000000000000072 000000000000006e 000000000000003f
      [   93.601453] 7dc0: 000000000000feff 000000000000fff1 ffffffbffc002028 0000000000000124
      [   93.609211] 7de0: ffffffc976be7e10 0000000000000001 ffffff8000000000 ffffffbbffff0000
      [   93.616969] 7e00: ffffffc976be7e60 0000000000000000 0000000000000000 0000000000000000
      [   93.624726] 7e20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      [   93.632484] 7e40: 0000007fcc474550 ffffffc0000841ec 000000002b424010 0000007facda0710
      [   93.640241] 7e60: ffffffffffffffff ffffffc0000be6dc ffffff80007d2000 000000000001c010
      [   93.647999] 7e80: ffffff80007e0ae0 ffffff80007e09d0 ffffff80007edf70 0000000000000288
      [   93.655757] 7ea0: 00000000000002e8 0000000000000000 0000000000000000 0000001c0000001b
      [   93.663514] 7ec0: 0000000000000009 0000000000000007 000000002b424090 000000000001c010
      [   93.671272] 7ee0: 000000002b424010 0000007faccd3a48 0000000000000000 0000000000000000
      [   93.679030] 7f00: 0000007fcc4743f8 0000007fcc4743f8 0000000000000069 0000000000000003
      [   93.686787] 7f20: 0101010101010101 0000000000000004 0000000000000020 00000000000003f3
      [   93.694544] 7f40: 0000007facb95664 0000007facda7030 0000007facc555d0 0000000000498378
      [   93.702301] 7f60: 0000000000000000 000000002b424010 0000007facda0710 000000002b424090
      [   93.710058] 7f80: 0000007fcc474698 0000000000498000 0000007fcc474ebb 0000000000474f58
      [   93.717815] 7fa0: 0000000000498000 0000000000000000 0000000000000000 0000007fcc474550
      [   93.725573] 7fc0: 00000000004104bc 0000007fcc474430 0000007facc555f4 0000000080000000
      [   93.733330] 7fe0: 000000002b424090 0000000000000069 0950020128000244 4104000008000004
      [   93.741084] Call trace:
      The above output makes a debugger life a lot more easier.
      Signed-off-by: default avatarRohit Thapliyal <r.thapliyal@samsung.com>
      Signed-off-by: default avatarManinder Singh <maninder1.s@samsung.com>
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
  7. 03 Jul, 2015 1 commit
  8. 19 Jun, 2015 1 commit
    • Vladimir Murzin's avatar
      arm64: use private ratelimit state along with show_unhandled_signals · 86dca36e
      Vladimir Murzin authored
      printk_ratelimit() shares the ratelimiting state with other callers what
      may lead to scenarios where at the time we want to print out debug
      information we already limited, so nothing appears in the dmesg - this
      makes exception-trace quite poor helper in debugging.
      Additionally, we have imbalance with some messages limited with global
      ratelimit state and other messages limited with their private state
      defined via pr_*_ratelimited().
      To address this inconsistency show_unhandled_signals_ratelimited()
      macro is introduced and caller sites are converted to use it.
      Signed-off-by: default avatarVladimir Murzin <vladimir.murzin@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
  9. 15 Jan, 2015 1 commit
  10. 20 Nov, 2014 1 commit
  11. 08 Sep, 2014 1 commit
  12. 23 Jul, 2014 1 commit
    • Jungseok Lee's avatar
      arm64: mm: Implement 4 levels of translation tables · c79b954b
      Jungseok Lee authored
      This patch implements 4 levels of translation tables since 3 levels
      of page tables with 4KB pages cannot support 40-bit physical address
      space described in [1] due to the following issue.
      It is a restriction that kernel logical memory map with 4KB + 3 levels
      (0xffffffc000000000-0xffffffffffffffff) cannot cover RAM region from
      544GB to 1024GB in [1]. Specifically, ARM64 kernel fails to create
      mapping for this region in map_mem function since __phys_to_virt for
      this region reaches to address overflow.
      If SoC design follows the document, [1], over 32GB RAM would be placed
      from 544GB. Even 64GB system is supposed to use the region from 544GB
      to 576GB for only 32GB RAM. Naturally, it would reach to enable 4 levels
      of page tables to avoid hacking __virt_to_phys and __phys_to_virt.
      However, it is recommended 4 levels of page table should be only enabled
      if memory map is too sparse or there is about 512GB RAM.
      [1]: Principles of ARM Memory Maps, White Paper, Issue C
      Signed-off-by: default avatarJungseok Lee <jays.lee@samsung.com>
      Reviewed-by: default avatarSungjinn Chung <sungjinn.chung@samsung.com>
      Acked-by: default avatarKukjin Kim <kgene.kim@samsung.com>
      Reviewed-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      Reviewed-by: default avatarSteve Capper <steve.capper@linaro.org>
      [catalin.marinas@arm.com: MEMBLOCK_INITIAL_LIMIT removed, same as PUD_SIZE]
      [catalin.marinas@arm.com: early_ioremap_init() updated for 4 levels]
      [catalin.marinas@arm.com: 48-bit VA depends on BROKEN until KVM is fixed]
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Tested-by: default avatarJungseok Lee <jungseoklee85@gmail.com>
  13. 17 Jul, 2014 1 commit
  14. 09 May, 2014 1 commit
  15. 12 Jun, 2013 1 commit
  16. 31 May, 2013 1 commit
  17. 24 May, 2013 1 commit
  18. 30 Apr, 2013 1 commit
    • Tejun Heo's avatar
      dump_stack: consolidate dump_stack() implementations and unify their behaviors · 196779b9
      Tejun Heo authored
      Both dump_stack() and show_stack() are currently implemented by each
      architecture.  show_stack(NULL, NULL) dumps the backtrace for the
      current task as does dump_stack().  On some archs, dump_stack() prints
      extra information - pid, utsname and so on - in addition to the
      backtrace while the two are identical on other archs.
      The usages in arch-independent code of the two functions indicate
      show_stack(NULL, NULL) should print out bare backtrace while
      dump_stack() is used for debugging purposes when something went wrong,
      so it does make sense to print additional information on the task which
      triggered dump_stack().
      There's no reason to require archs to implement two separate but mostly
      identical functions.  It leads to unnecessary subtle information.
      This patch expands the dummy fallback dump_stack() implementation in
      lib/dump_stack.c such that it prints out debug information (taken from
      x86) and invokes show_stack(NULL, NULL) and drops arch-specific
      dump_stack() implementations in all archs except blackfin.  Blackfin's
      dump_stack() does something wonky that I don't understand.
      Debug information can be printed separately by calling
      dump_stack_print_info() so that arch-specific dump_stack()
      implementation can still emit the same debug information.  This is used
      in blackfin.
      This patch brings the following behavior changes.
      * On some archs, an extra level in backtrace for show_stack() could be
        printed.  This is because the top frame was determined in
        dump_stack() on those archs while generic dump_stack() can't do that
        reliably.  It can be compensated by inlining dump_stack() but not
        sure whether that'd be necessary.
      * Most archs didn't use to print debug info on dump_stack().  They do
      An example WARN dump follows.
       WARNING: at kernel/workqueue.c:4841 init_workqueues+0x35/0x505()
       Hardware name: empty
       Modules linked in:
       CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.9.0-rc1-work+ #9
        0000000000000009 ffff88007c861e08 ffffffff81c614dc ffff88007c861e48
        ffffffff8108f50f ffffffff82228240 0000000000000040 ffffffff8234a03c
        0000000000000000 0000000000000000 0000000000000000 ffff88007c861e58
       Call Trace:
        [<ffffffff81c614dc>] dump_stack+0x19/0x1b
        [<ffffffff8108f50f>] warn_slowpath_common+0x7f/0xc0
        [<ffffffff8108f56a>] warn_slowpath_null+0x1a/0x20
        [<ffffffff8234a071>] init_workqueues+0x35/0x505
      v2: CPU number added to the generic debug info as requested by s390
          folks and dropped the s390 specific dump_stack().  This loses %ksp
          from the debug message which the maintainers think isn't important
          enough to keep the s390-specific dump_stack() implementation.
          dump_stack_print_info() is moved to kernel/printk.c from
          lib/dump_stack.c.  Because linkage is per objecct file,
          dump_stack_print_info() living in the same lib file as generic
          dump_stack() means that archs which implement custom dump_stack()
          - at this point, only blackfin - can't use dump_stack_print_info()
          as that will bring in the generic version of dump_stack() too.  v1
          The v1 patch broke build on blackfin due to this issue.  The build
          breakage was reported by Fengguang Wu.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Acked-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Acked-by: default avatarJesper Nilsson <jesper.nilsson@axis.com>
      Acked-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Acked-by: Martin Schwidefsky <schwidefsky@de.ibm.com>	[s390 bits]
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Mike Frysinger <vapier@gentoo.org>
      Cc: Fengguang Wu <fengguang.wu@intel.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Acked-by: Richard Kuo <rkuo@codeaurora.org>		[hexagon bits]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  19. 20 Jan, 2013 1 commit
  20. 17 Sep, 2012 1 commit