1. 24 Feb, 2022 1 commit
    • Nicholas Piggin's avatar
      powerpc/64s/hash: Make hash faults work in NMI context · 8b91cee5
      Nicholas Piggin authored
      Hash faults are not resoved in NMI context, instead causing the access
      to fail. This is done because perf interrupts can get backtraces
      including walking the user stack, and taking a hash fault on those could
      deadlock on the HPTE lock if the perf interrupt hits while the same HPTE
      lock is being held by the hash fault code. The user-access for the stack
      walking will notice the access failed and deal with that in the perf
      code.
      
      The reason to allow perf interrupts in is to better profile hash faults.
      
      The problem with this is any hash fault on a kernel access that happens
      in NMI context will crash, because kernel accesses must not fail.
      
      Hard lockups, system reset, machine checks that access vmalloc space
      including modules and including stack backtracing and symbol lookup in
      modules, per-cpu data, etc could all run into this problem.
      
      Fix this by disallowing perf interrupts in the hash fault code (the
      direct hash fault is covered by MSR[EE]=0 so the PMI disable just needs
      to extend to the preload case). This simplifies the tricky logic in hash
      faults and perf, at the cost of reduced profiling of hash faults.
      
      perf can still latch addresses when interrupts are disabled, it just
      won't get the stack trace at that point, so it would still find hot
      spots, just sometimes with confusing stack chains.
      
      An alternative could be to allow perf interrupts here but always do the
      slowpath stack walk if we are in nmi context, but that slows down all
      perf interrupt stack walking on hash though and it does not remove as
      much tricky code.
      Reported-by: default avatarLaurent Dufour <ldufour@linux.ibm.com>
      Signed-off-by: default avatarNicholas Piggin <npiggin@gmail.com>
      Tested-by: default avatarLaurent Dufour <ldufour@linux.ibm.com>
      Reviewed-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20220204035348.545435-1-npiggin@gmail.com
      8b91cee5
  2. 23 Feb, 2022 1 commit
  3. 16 Feb, 2022 5 commits
  4. 15 Feb, 2022 1 commit
  5. 14 Feb, 2022 1 commit
  6. 12 Feb, 2022 18 commits
  7. 07 Feb, 2022 13 commits