1. 19 10月, 2016 1 次提交
  2. 12 10月, 2016 2 次提交
  3. 08 10月, 2016 3 次提交
  4. 29 9月, 2016 3 次提交
  5. 28 9月, 2016 3 次提交
  6. 27 9月, 2016 6 次提交
  7. 26 9月, 2016 2 次提交
    • K
      arm64: Kconfig: select OF/ACPI_NUMA under NUMA config · 0c2a6cce
      Kefeng Wang 提交于
      Move OF_NUMA select under NUMA config, and select ACPI_NUMA
      when ACPI enabled.
      Signed-off-by: NKefeng Wang <wangkefeng.wang@huawei.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      0c2a6cce
    • M
      arm64: fix dump_backtrace/unwind_frame with NULL tsk · b5e7307d
      Mark Rutland 提交于
      In some places, dump_backtrace() is called with a NULL tsk parameter,
      e.g. in bug_handler() in arch/arm64, or indirectly via show_stack() in
      core code. The expectation is that this is treated as if current were
      passed instead of NULL. Similar is true of unwind_frame().
      
      Commit a80a0eb7 ("arm64: make irq_stack_ptr more robust") didn't
      take this into account. In dump_backtrace() it compares tsk against
      current *before* we check if tsk is NULL, and in unwind_frame() we never
      set tsk if it is NULL.
      
      Due to this, we won't initialise irq_stack_ptr in either function. In
      dump_backtrace() this results in calling dump_mem() for memory
      immediately above the IRQ stack range, rather than for the relevant
      range on the task stack. In unwind_frame we'll reject unwinding frames
      on the IRQ stack.
      
      In either case this results in incomplete or misleading backtrace
      information, but is not otherwise problematic. The initial percpu areas
      (including the IRQ stacks) are allocated in the linear map, and dump_mem
      uses __get_user(), so we shouldn't access anything with side-effects,
      and will handle holes safely.
      
      This patch fixes the issue by having both functions handle the NULL tsk
      case before doing anything else with tsk.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Fixes: a80a0eb7 ("arm64: make irq_stack_ptr more robust")
      Acked-by: NJames Morse <james.morse@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Yang Shi <yang.shi@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      b5e7307d
  8. 24 9月, 2016 2 次提交
  9. 23 9月, 2016 2 次提交
    • A
      arm64: kgdb: handle read-only text / modules · 67787b68
      AKASHI Takahiro 提交于
      Handle read-only cases when CONFIG_DEBUG_RODATA (4.0) or
      CONFIG_DEBUG_SET_MODULE_RONX (3.18) are enabled by using
      aarch64_insn_write() instead of probe_kernel_write() as introduced by
      commit 2f896d58 ("arm64: use fixmap for text patching") in 4.0.
      
      Fixes: 11d91a77 ("arm64: Add CONFIG_DEBUG_SET_MODULE_RONX support")
      Signed-off-by: NAKASHI Takahiro <takahiro.akashi@linaro.org>
      Reviewed-by: NMark Rutland <mark.rutland@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      67787b68
    • D
      arm64: Call numa_store_cpu_info() earlier. · c18df0ad
      David Daney 提交于
      The wq_numa_init() function makes a private CPU to node map by calling
      cpu_to_node() early in the boot process, before the non-boot CPUs are
      brought online.  Since the default implementation of cpu_to_node()
      returns zero for CPUs that have never been brought online, the
      workqueue system's view is that *all* CPUs are on node zero.
      
      When the unbound workqueue for a non-zero node is created, the
      tsk_cpus_allowed() for the worker threads is the empty set because
      there are, in the view of the workqueue system, no CPUs on non-zero
      nodes.  The code in try_to_wake_up() using this empty cpumask ends up
      using the cpumask empty set value of NR_CPUS as an index into the
      per-CPU area pointer array, and gets garbage as it is one past the end
      of the array.  This results in:
      
      [    0.881970] Unable to handle kernel paging request at virtual address fffffb1008b926a4
      [    1.970095] pgd = fffffc00094b0000
      [    1.973530] [fffffb1008b926a4] *pgd=0000000000000000, *pud=0000000000000000, *pmd=0000000000000000
      [    1.982610] Internal error: Oops: 96000004 [#1] SMP
      [    1.987541] Modules linked in:
      [    1.990631] CPU: 48 PID: 295 Comm: cpuhp/48 Tainted: G        W       4.8.0-rc6-preempt-vol+ #9
      [    1.999435] Hardware name: Cavium ThunderX CN88XX board (DT)
      [    2.005159] task: fffffe0fe89cc300 task.stack: fffffe0fe8b8c000
      [    2.011158] PC is at try_to_wake_up+0x194/0x34c
      [    2.015737] LR is at try_to_wake_up+0x150/0x34c
      [    2.020318] pc : [<fffffc00080e7468>] lr : [<fffffc00080e7424>] pstate: 600000c5
      [    2.027803] sp : fffffe0fe8b8fb10
      [    2.031149] x29: fffffe0fe8b8fb10 x28: 0000000000000000
      [    2.036522] x27: fffffc0008c63bc8 x26: 0000000000001000
      [    2.041896] x25: fffffc0008c63c80 x24: fffffc0008bfb200
      [    2.047270] x23: 00000000000000c0 x22: 0000000000000004
      [    2.052642] x21: fffffe0fe89d25bc x20: 0000000000001000
      [    2.058014] x19: fffffe0fe89d1d00 x18: 0000000000000000
      [    2.063386] x17: 0000000000000000 x16: 0000000000000000
      [    2.068760] x15: 0000000000000018 x14: 0000000000000000
      [    2.074133] x13: 0000000000000000 x12: 0000000000000000
      [    2.079505] x11: 0000000000000000 x10: 0000000000000000
      [    2.084879] x9 : 0000000000000000 x8 : 0000000000000000
      [    2.090251] x7 : 0000000000000040 x6 : 0000000000000000
      [    2.095621] x5 : ffffffffffffffff x4 : 0000000000000000
      [    2.100991] x3 : 0000000000000000 x2 : 0000000000000000
      [    2.106364] x1 : fffffc0008be4c24 x0 : ffffff0ffffada80
      [    2.111737]
      [    2.113236] Process cpuhp/48 (pid: 295, stack limit = 0xfffffe0fe8b8c020)
      [    2.120102] Stack: (0xfffffe0fe8b8fb10 to 0xfffffe0fe8b90000)
      [    2.125914] fb00:                                   fffffe0fe8b8fb80 fffffc00080e7648
      .
      .
      .
      [    2.442859] Call trace:
      [    2.445327] Exception stack(0xfffffe0fe8b8f940 to 0xfffffe0fe8b8fa70)
      [    2.451843] f940: fffffe0fe89d1d00 0000040000000000 fffffe0fe8b8fb10 fffffc00080e7468
      [    2.459767] f960: fffffe0fe8b8f980 fffffc00080e4958 ffffff0ff91ab200 fffffc00080e4b64
      [    2.467690] f980: fffffe0fe8b8f9d0 fffffc00080e515c fffffe0fe8b8fa80 0000000000000000
      [    2.475614] f9a0: fffffe0fe8b8f9d0 fffffc00080e58e4 fffffe0fe8b8fa80 0000000000000000
      [    2.483540] f9c0: fffffe0fe8d10000 0000000000000040 fffffe0fe8b8fa50 fffffc00080e5ac4
      [    2.491465] f9e0: ffffff0ffffada80 fffffc0008be4c24 0000000000000000 0000000000000000
      [    2.499387] fa00: 0000000000000000 ffffffffffffffff 0000000000000000 0000000000000040
      [    2.507309] fa20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      [    2.515233] fa40: 0000000000000000 0000000000000000 0000000000000000 0000000000000018
      [    2.523156] fa60: 0000000000000000 0000000000000000
      [    2.528089] [<fffffc00080e7468>] try_to_wake_up+0x194/0x34c
      [    2.533723] [<fffffc00080e7648>] wake_up_process+0x28/0x34
      [    2.539275] [<fffffc00080d3764>] create_worker+0x110/0x19c
      [    2.544824] [<fffffc00080d69dc>] alloc_unbound_pwq+0x3cc/0x4b0
      [    2.550724] [<fffffc00080d6bcc>] wq_update_unbound_numa+0x10c/0x1e4
      [    2.557066] [<fffffc00080d7d78>] workqueue_online_cpu+0x220/0x28c
      [    2.563234] [<fffffc00080bd288>] cpuhp_invoke_callback+0x6c/0x168
      [    2.569398] [<fffffc00080bdf74>] cpuhp_up_callbacks+0x44/0xe4
      [    2.575210] [<fffffc00080be194>] cpuhp_thread_fun+0x13c/0x148
      [    2.581027] [<fffffc00080dfbac>] smpboot_thread_fn+0x19c/0x1a8
      [    2.586929] [<fffffc00080dbd64>] kthread+0xdc/0xf0
      [    2.591776] [<fffffc0008083380>] ret_from_fork+0x10/0x50
      [    2.597147] Code: b00057e1 91304021 91005021 b8626822 (b8606821)
      [    2.603464] ---[ end trace 58c0cd36b88802bc ]---
      [    2.608138] Kernel panic - not syncing: Fatal exception
      
      Fix by moving call to numa_store_cpu_info() for all CPUs into
      smp_prepare_cpus(), which happens before wq_numa_init().  Since
      smp_store_cpu_info() now contains only a single function call,
      simplify by removing the function and out-lining its contents.
      Suggested-by: NRobert Richter <rric@kernel.org>
      Fixes: 1a2db300 ("arm64, numa: Add NUMA support for arm64 platforms.")
      Cc: <stable@vger.kernel.org> # 4.7.x-
      Signed-off-by: NDavid Daney <david.daney@cavium.com>
      Reviewed-by: NRobert Richter <rrichter@cavium.com>
      Tested-by: NYisheng Xie <xieyisheng1@huawei.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      c18df0ad
  10. 22 9月, 2016 6 次提交
  11. 20 9月, 2016 2 次提交
  12. 17 9月, 2016 3 次提交
  13. 16 9月, 2016 5 次提交