1. 25 Jun, 2019 2 commits
  2. 24 Jun, 2019 6 commits
  3. 21 Jun, 2019 8 commits
    • Julien Thierry's avatar
      arm64: Allow selecting Pseudo-NMI again · 2a438ffa
      Julien Thierry authored
      Now that Pseudo-NMI are fixed, allow the use of that option again
      
      This reverts commit 96a13f57 ("arm64:
      Kconfig: Make ARM64_PSEUDO_NMI depend on BROKEN for now").
      
      Cc: Will Deacon <will.deacon@arm.com>
      Reviewed-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarJulien Thierry <julien.thierry@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      2a438ffa
    • Wei Li's avatar
      arm64: fix kernel stack overflow in kdump capture kernel · e1d22385
      Wei Li authored
      When enabling ARM64_PSEUDO_NMI feature in kdump capture kernel, it will
      report a kernel stack overflow exception:
      
      [    0.000000] CPU features: detected: IRQ priority masking
      [    0.000000] alternatives: patching kernel code
      [    0.000000] Insufficient stack space to handle exception!
      [    0.000000] ESR: 0x96000044 -- DABT (current EL)
      [    0.000000] FAR: 0x0000000000000040
      [    0.000000] Task stack:     [0xffff0000097f0000..0xffff0000097f4000]
      [    0.000000] IRQ stack:      [0x0000000000000000..0x0000000000004000]
      [    0.000000] Overflow stack: [0xffff80002b7cf290..0xffff80002b7d0290]
      [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.34-lw+ #3
      [    0.000000] pstate: 400003c5 (nZcv DAIF -PAN -UAO)
      [    0.000000] pc : el1_sync+0x0/0xb8
      [    0.000000] lr : el1_irq+0xb8/0x140
      [    0.000000] sp : 0000000000000040
      [    0.000000] pmr_save: 00000070
      [    0.000000] x29: ffff0000097f3f60 x28: ffff000009806240
      [    0.000000] x27: 0000000080000000 x26: 0000000000004000
      [    0.000000] x25: 0000000000000000 x24: ffff000009329028
      [    0.000000] x23: 0000000040000005 x22: ffff000008095c6c
      [    0.000000] x21: ffff0000097f3f70 x20: 0000000000000070
      [    0.000000] x19: ffff0000097f3e30 x18: ffffffffffffffff
      [    0.000000] x17: 0000000000000000 x16: 0000000000000000
      [    0.000000] x15: ffff0000097f9708 x14: ffff000089a382ef
      [    0.000000] x13: ffff000009a382fd x12: ffff000009824000
      [    0.000000] x11: ffff0000097fb7b0 x10: ffff000008730028
      [    0.000000] x9 : ffff000009440018 x8 : 000000000000000d
      [    0.000000] x7 : 6b20676e69686374 x6 : 000000000000003b
      [    0.000000] x5 : 0000000000000000 x4 : ffff000008093600
      [    0.000000] x3 : 0000000400000008 x2 : 7db2e689fc2b8e00
      [    0.000000] x1 : 0000000000000000 x0 : ffff0000097f3e30
      [    0.000000] Kernel panic - not syncing: kernel stack overflow
      [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.34-lw+ #3
      [    0.000000] Call trace:
      [    0.000000]  dump_backtrace+0x0/0x1b8
      [    0.000000]  show_stack+0x24/0x30
      [    0.000000]  dump_stack+0xa8/0xcc
      [    0.000000]  panic+0x134/0x30c
      [    0.000000]  __stack_chk_fail+0x0/0x28
      [    0.000000]  handle_bad_stack+0xfc/0x108
      [    0.000000]  __bad_stack+0x90/0x94
      [    0.000000]  el1_sync+0x0/0xb8
      [    0.000000]  init_gic_priority_masking+0x4c/0x70
      [    0.000000]  smp_prepare_boot_cpu+0x60/0x68
      [    0.000000]  start_kernel+0x1e8/0x53c
      [    0.000000] ---[ end Kernel panic - not syncing: kernel stack overflow ]---
      
      The reason is init_gic_priority_masking() may unmask PSR.I while the
      irq stacks are not inited yet. Some "NMI" could be raised unfortunately
      and it will just go into this exception.
      
      In this patch, we just write the PMR in smp_prepare_boot_cpu(), and delay
      unmasking PSR.I after irq stacks inited in init_IRQ().
      
      Fixes: e7932188 ("arm64: Switch to PMR masking when starting CPUs")
      Cc: Will Deacon <will.deacon@arm.com>
      Reviewed-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarWei Li <liwei391@huawei.com>
      [JT: make init_gic_priority_masking() not modify daif, rebase on other
           priority masking fixes]
      Signed-off-by: default avatarJulien Thierry <julien.thierry@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      e1d22385
    • Julien Thierry's avatar
      arm64: irqflags: Introduce explicit debugging for IRQ priorities · 48ce8f80
      Julien Thierry authored
      Using IRQ priority masking to enable/disable interrupts is a bit
      sensitive as it requires to deal with both ICC_PMR_EL1 and PSR.I.
      
      Introduce some validity checks to both highlight the states in which
      functions dealing with IRQ enabling/disabling can (not) be called, and
      bark a warning when called in an unexpected state.
      
      Since these checks are done on hotpaths, introduce a build option to
      choose whether to do the checking.
      
      Cc: Will Deacon <will.deacon@arm.com>
      Reviewed-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarJulien Thierry <julien.thierry@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      48ce8f80
    • Julien Thierry's avatar
      arm64: Fix incorrect irqflag restore for priority masking · bd82d4bd
      Julien Thierry authored
      When using IRQ priority masking to disable interrupts, in order to deal
      with the PSR.I state, local_irq_save() would convert the I bit into a
      PMR value (GIC_PRIO_IRQOFF). This resulted in local_irq_restore()
      potentially modifying the value of PMR in undesired location due to the
      state of PSR.I upon flag saving [1].
      
      In an attempt to solve this issue in a less hackish manner, introduce
      a bit (GIC_PRIO_IGNORE_PMR) for the PMR values that can represent
      whether PSR.I is being used to disable interrupts, in which case it
      takes precedence of the status of interrupt masking via PMR.
      
      GIC_PRIO_PSR_I_SET is chosen such that (<pmr_value> |
      GIC_PRIO_PSR_I_SET) does not mask more interrupts than <pmr_value> as
      some sections (e.g. arch_cpu_idle(), interrupt acknowledge path)
      requires PMR not to mask interrupts that could be signaled to the
      CPU when using only PSR.I.
      
      [1] https://www.spinics.net/lists/arm-kernel/msg716956.html
      
      Fixes: 4a503217 ("arm64: irqflags: Use ICC_PMR_EL1 for interrupt masking")
      Cc: <stable@vger.kernel.org> # 5.1.x-
      Reported-by: default avatarZenghui Yu <yuzenghui@huawei.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Wei Li <liwei391@huawei.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Christoffer Dall <christoffer.dall@arm.com>
      Cc: James Morse <james.morse@arm.com>
      Cc: Suzuki K Pouloze <suzuki.poulose@arm.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Reviewed-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarJulien Thierry <julien.thierry@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      bd82d4bd
    • Julien Thierry's avatar
      arm64: Fix interrupt tracing in the presence of NMIs · 17ce302f
      Julien Thierry authored
      In the presence of any form of instrumentation, nmi_enter() should be
      done before calling any traceable code and any instrumentation code.
      
      Currently, nmi_enter() is done in handle_domain_nmi(), which is much
      too late as instrumentation code might get called before. Move the
      nmi_enter/exit() calls to the arch IRQ vector handler.
      
      On arm64, it is not possible to know if the IRQ vector handler was
      called because of an NMI before acknowledging the interrupt. However, It
      is possible to know whether normal interrupts could be taken in the
      interrupted context (i.e. if taking an NMI in that context could
      introduce a potential race condition).
      
      When interrupting a context with IRQs disabled, call nmi_enter() as soon
      as possible. In contexts with IRQs enabled, defer this to the interrupt
      controller, which is in a better position to know if an interrupt taken
      is an NMI.
      
      Fixes: bc3c03cc ("arm64: Enable the support of pseudo-NMIs")
      Cc: <stable@vger.kernel.org> # 5.1.x-
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Reviewed-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarJulien Thierry <julien.thierry@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      17ce302f
    • Julien Thierry's avatar
      arm64: irqflags: Add condition flags to inline asm clobber list · f5706578
      Julien Thierry authored
      Some of the inline assembly instruction use the condition flags and need
      to include "cc" in the clobber list.
      
      Fixes: 4a503217 ("arm64: irqflags: Use ICC_PMR_EL1 for interrupt masking")
      Cc: <stable@vger.kernel.org> # 5.1.x-
      Suggested-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Reviewed-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarJulien Thierry <julien.thierry@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      f5706578
    • Julien Thierry's avatar
      arm64: irqflags: Pass flags as readonly operand to restore instruction · 19c36b18
      Julien Thierry authored
      Flags are only read by the instructions doing the irqflags restore
      operation. Pass the operand as read only to the asm inline instead of
      read-write.
      
      Cc: Will Deacon <will.deacon@arm.com>
      Reviewed-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Acked-by: default avatarMark Rutland <mark.rutland@ar.com>
      Signed-off-by: default avatarJulien Thierry <julien.thierry@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      19c36b18
    • Julien Thierry's avatar
      arm64: Do not enable IRQs for ct_user_exit · 9034f625
      Julien Thierry authored
      For el0_dbg and el0_error, DAIF bits get explicitly cleared before
      calling ct_user_exit.
      
      When context tracking is disabled, DAIF gets set (almost) immediately
      after. When context tracking is enabled, among the first things done
      is disabling IRQs.
      
      What is actually needed is:
      - PSR.D = 0 so the system can be debugged (should be already the case)
      - PSR.A = 0 so async error can be handled during context tracking
      
      Do not clear PSR.I in those two locations.
      Reviewed-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Reviewed-by: default avatarJames Morse <james.morse@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarJulien Thierry <julien.thierry@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      9034f625
  4. 17 Jun, 2019 1 commit
  5. 14 Jun, 2019 1 commit
    • Bartlomiej Zolnierkiewicz's avatar
      arm64: remove redundant 'default n' from Kconfig · 1a2a66db
      Bartlomiej Zolnierkiewicz authored
      'default n' is the default value for any bool or tristate Kconfig
      setting so there is no need to write it explicitly.
      
      Also since commit f467c564 ("kconfig: only write '# CONFIG_FOO
      is not set' for visible symbols") the Kconfig behavior is the same
      regardless of 'default n' being present or not:
      
          ...
          One side effect of (and the main motivation for) this change is making
          the following two definitions behave exactly the same:
      
              config FOO
                      bool
      
              config FOO
                      bool
                      default n
      
          With this change, neither of these will generate a
          '# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
          That might make it clearer to people that a bare 'default n' is
          redundant.
          ...
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      1a2a66db
  6. 10 Jun, 2019 1 commit
    • Mark Rutland's avatar
      arm64: mm: avoid redundant READ_ONCE(*ptep) · 9b604722
      Mark Rutland authored
      In set_pte_at(), we read the old pte value so that it can be passed into
      checks for racy hw updates. These checks are only performed for
      CONFIG_DEBUG_VM, and the value is not used otherwise.
      
      Since we read the pte value with READ_ONCE(), the compiler cannot elide
      the redundant read for !CONFIG_DEBUG_VM kernels.
      
      Let's ameliorate matters by moving the read and the checks into a
      helper, __check_racy_pte_update(), which only performs the read when the
      value will be used. This also allows us to reformat the conditions for
      clarity.
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      9b604722
  7. 07 Jun, 2019 3 commits
  8. 05 Jun, 2019 3 commits
    • Sudeep Holla's avatar
      arm64: ptrace: add support for syscall emulation · f086f674
      Sudeep Holla authored
      Add PTRACE_SYSEMU and PTRACE_SYSEMU_SINGLESTEP support on arm64.
      We don't need any special handling for PTRACE_SYSEMU_SINGLESTEP.
      
      It's quite difficult to generalize handling PTRACE_SYSEMU cross
      architectures and avoid calls to tracehook_report_syscall_entry twice.
      Different architecture have different mechanism to indicate NO_SYSCALL
      and trying to generalise adds more code for no gain.
      
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      f086f674
    • Sudeep Holla's avatar
      arm64: add PTRACE_SYSEMU{,SINGLESTEP} definations to uapi headers · fd386638
      Sudeep Holla authored
      x86 and um use 31 and 32 for PTRACE_SYSEMU and PTRACE_SYSEMU_SINGLESTEP
      while powerpc uses different value maybe for legacy reasons.
      
      Though handling of PTRACE_SYSEMU can be made architecture independent,
      it's hard to make these definations generic. To add to this existing
      mess few architectures like arm, c6x and sh use 31 for PTRACE_GETFDPIC
      (get the ELF fdpic loadmap address). It's not possible to move the
      definations to generic headers.
      
      So we unfortunately have to duplicate the same defination to ARM64 if
      we need to support PTRACE_SYSEMU and PTRACE_SYSEMU_SINGLESTEP.
      
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      fd386638
    • Sudeep Holla's avatar
      ptrace: move clearing of TIF_SYSCALL_EMU flag to core · 15532fd6
      Sudeep Holla authored
      While the TIF_SYSCALL_EMU is set in ptrace_resume independent of any
      architecture, currently only powerpc and x86 unset the TIF_SYSCALL_EMU
      flag in ptrace_disable which gets called from ptrace_detach.
      
      Let's move the clearing of TIF_SYSCALL_EMU flag to __ptrace_unlink
      which gets executed from ptrace_detach and also keep it along with
      or close to clearing of TIF_SYSCALL_TRACE.
      
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Acked-by: default avatarOleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      15532fd6
  9. 04 Jun, 2019 13 commits
  10. 03 Jun, 2019 2 commits