1. 18 5月, 2018 8 次提交
  2. 17 5月, 2018 14 次提交
  3. 15 5月, 2018 1 次提交
  4. 27 4月, 2018 2 次提交
  5. 25 4月, 2018 2 次提交
    • N
      powerpc: Fix smp_send_stop NMI IPI handling · ac61c115
      Nicholas Piggin 提交于
      The NMI IPI handler for a receiving CPU increments nmi_ipi_busy_count
      over the handler function call, which causes later smp_send_nmi_ipi()
      callers to spin until the call is finished.
      
      The stop_this_cpu() function never returns, so the busy count is never
      decremeted, which can cause the system to hang in some cases. For
      example panic() will call smp_send_stop() early on which calls
      stop_this_cpu() on other CPUs, then later in the reboot path,
      pnv_restart() will call smp_send_stop() again, which hangs.
      
      Fix this by adding a special case to the stop_this_cpu() handler to
      decrement the busy count, because it will never return.
      
      Now that the NMI/non-NMI versions of stop_this_cpu() are different,
      split them out into separate functions rather than doing #ifdef tricks
      to share the body between the two functions.
      
      Fixes: 6bed3237 ("powerpc: use NMI IPI for smp_send_stop")
      Reported-by: NAbdul Haleem <abdhalee@linux.vnet.ibm.com>
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      [mpe: Split out the functions, tweak change log a bit]
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      ac61c115
    • N
      rtc: opal: Fix OPAL RTC driver OPAL_BUSY loops · 682e6b4d
      Nicholas Piggin 提交于
      The OPAL RTC driver does not sleep in case it gets OPAL_BUSY or
      OPAL_BUSY_EVENT from firmware, which causes large scheduling
      latencies, up to 50 seconds have been observed here when RTC stops
      responding (BMC reboot can do it).
      
      Fix this by converting it to the standard form OPAL_BUSY loop that
      sleeps.
      
      Fixes: 628daa8d ("powerpc/powernv: Add RTC and NVRAM support plus RTAS fallbacks")
      Cc: stable@vger.kernel.org # v3.2+
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Acked-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      682e6b4d
  6. 24 4月, 2018 6 次提交
    • M
      powerpc/mce: Fix a bug where mce loops on memory UE. · 75ecfb49
      Mahesh Salgaonkar 提交于
      The current code extracts the physical address for UE errors and then
      hooks it up into memory failure infrastructure. On successful
      extraction of physical address it wrongly sets "handled = 1" which
      means this UE error has been recovered. Since MCE handler gets return
      value as handled = 1, it assumes that error has been recovered and
      goes back to same NIP. This causes MCE interrupt again and again in a
      loop leading to hard lockup.
      
      Also, initialize phys_addr to ULONG_MAX so that we don't end up
      queuing undesired page to hwpoison.
      
      Without this patch we see:
        Severe Machine check interrupt [Recovered]
          NIP: [000000001002588c] PID: 7109 Comm: find
          Initiator: CPU
          Error type: UE [Load/Store]
            Effective address: 00007fffd2755940
            Physical address:  000020181a080000
        ...
        Severe Machine check interrupt [Recovered]
          NIP: [000000001002588c] PID: 7109 Comm: find
          Initiator: CPU
          Error type: UE [Load/Store]
            Effective address: 00007fffd2755940
            Physical address:  000020181a080000
        Severe Machine check interrupt [Recovered]
          NIP: [000000001002588c] PID: 7109 Comm: find
          Initiator: CPU
          Error type: UE [Load/Store]
            Effective address: 00007fffd2755940
            Physical address:  000020181a080000
        Memory failure: 0x20181a08: recovery action for dirty LRU page: Recovered
        Memory failure: 0x20181a08: already hardware poisoned
        Memory failure: 0x20181a08: already hardware poisoned
        Memory failure: 0x20181a08: already hardware poisoned
        Memory failure: 0x20181a08: already hardware poisoned
        Memory failure: 0x20181a08: already hardware poisoned
        Memory failure: 0x20181a08: already hardware poisoned
        ...
        Watchdog CPU:38 Hard LOCKUP
      
      After this patch we see:
      
        Severe Machine check interrupt [Not recovered]
          NIP: [00007fffaae585f4] PID: 7168 Comm: find
          Initiator: CPU
          Error type: UE [Load/Store]
            Effective address: 00007fffaafe28ac
            Physical address:  00002017c0bd0000
        find[7168]: unhandled signal 7 at 00007fffaae585f4 nip 00007fffaae585f4 lr 00007fffaae585e0 code 4
        Memory failure: 0x2017c0bd: recovery action for dirty LRU page: Recovered
      
      Fixes: 01eaac2b ("powerpc/mce: Hookup ierror (instruction) UE errors")
      Fixes: ba41e1e1 ("powerpc/mce: Hookup derror (load/store) UE errors")
      Cc: stable@vger.kernel.org # v4.15+
      Signed-off-by: NMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Signed-off-by: NBalbir Singh <bsingharora@gmail.com>
      Reviewed-by: NBalbir Singh <bsingharora@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      75ecfb49
    • A
      powerpc/powernv/npu: Do a PID GPU TLB flush when invalidating a large address range · d0cf9b56
      Alistair Popple 提交于
      The NPU has a limited number of address translation shootdown (ATSD)
      registers and the GPU has limited bandwidth to process ATSDs. This can
      result in contention of ATSD registers leading to soft lockups on some
      threads, particularly when invalidating a large address range in
      pnv_npu2_mn_invalidate_range().
      
      At some threshold it becomes more efficient to flush the entire GPU
      TLB for the given MM context (PID) than individually flushing each
      address in the range. This patch will result in ranges greater than
      2MB being converted from 32+ ATSDs into a single ATSD which will flush
      the TLB for the given PID on each GPU.
      
      Fixes: 1ab66d1f ("powerpc/powernv: Introduce address translation services for Nvlink2")
      Cc: stable@vger.kernel.org # v4.12+
      Signed-off-by: NAlistair Popple <alistair@popple.id.au>
      Acked-by: NBalbir Singh <bsingharora@gmail.com>
      Tested-by: NBalbir Singh <bsingharora@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      d0cf9b56
    • A
      powerpc/powernv/npu: Prevent overwriting of pnv_npu2_init_contex() callback parameters · a1409ada
      Alistair Popple 提交于
      There is a single npu context per set of callback parameters. Callers
      should be prevented from overwriting existing callback values so
      instead return an error if different parameters are passed.
      
      Fixes: 1ab66d1f ("powerpc/powernv: Introduce address translation services for Nvlink2")
      Cc: stable@vger.kernel.org # v4.12+
      Signed-off-by: NAlistair Popple <alistair@popple.id.au>
      Reviewed-by: NMark Hairgrove <mhairgrove@nvidia.com>
      Tested-by: NMark Hairgrove <mhairgrove@nvidia.com>
      Reviewed-by: NBalbir Singh <bsingharora@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      a1409ada
    • A
      powerpc/powernv/npu: Add lock to prevent race in concurrent context init/destroy · 28a5933e
      Alistair Popple 提交于
      The pnv_npu2_init_context() and pnv_npu2_destroy_context() functions
      are used to allocate/free contexts to allow address translation and
      shootdown by the NPU on a particular GPU. Context initialisation is
      implicitly safe as it is protected by the requirement mmap_sem be held
      in write mode, however pnv_npu2_destroy_context() does not require
      mmap_sem to be held and it is not safe to call with a concurrent
      initialisation for a different GPU.
      
      It was assumed the driver would ensure destruction was not called
      concurrently with initialisation. However the driver may be simplified
      by allowing concurrent initialisation and destruction for different
      GPUs. As npu context creation/destruction is not a performance
      critical path and the critical section is not large a single spinlock
      is used for simplicity.
      
      Fixes: 1ab66d1f ("powerpc/powernv: Introduce address translation services for Nvlink2")
      Cc: stable@vger.kernel.org # v4.12+
      Signed-off-by: NAlistair Popple <alistair@popple.id.au>
      Reviewed-by: NMark Hairgrove <mhairgrove@nvidia.com>
      Tested-by: NMark Hairgrove <mhairgrove@nvidia.com>
      Reviewed-by: NBalbir Singh <bsingharora@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      28a5933e
    • B
      powerpc/powernv/memtrace: Let the arch hotunplug code flush cache · 7fd6641d
      Balbir Singh 提交于
      Don't do this via custom code, instead now that we have support in the
      arch hotplug/hotunplug code, rely on those routines to do the right
      thing.
      
      The existing flush doesn't work because it uses ppc64_caches.l1d.size
      instead of ppc64_caches.l1d.line_size.
      
      Fixes: 9d5171a8 ("powerpc/powernv: Enable removal of memory for in memory tracing")
      Signed-off-by: NBalbir Singh <bsingharora@gmail.com>
      Reviewed-by: NRashmica Gupta <rashmica.g@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      7fd6641d
    • B
      powerpc/mm: Flush cache on memory hot(un)plug · fb5924fd
      Balbir Singh 提交于
      This patch adds support for flushing potentially dirty cache lines
      when memory is hot-plugged/hot-un-plugged. The support is currently
      limited to 64 bit systems.
      
      The bug was exposed when mappings for a device were actually
      hot-unplugged and plugged in back later. A similar issue was observed
      during the development of memtrace, but memtrace does it's own
      flushing of region via a custom routine.
      
      These patches do a flush both on hotplug/unplug to clear any stale
      data in the cache w.r.t mappings, there is a small race window where a
      clean cache line may be created again just prior to tearing down the
      mapping.
      
      The patches were tested by disabling the flush routines in memtrace
      and doing I/O on the trace file. The system immediately
      checkstops (quite reliablly if prior to the hot-unplug of the memtrace
      region, we memset the regions we are about to hot unplug). After these
      patches no custom flushing is needed in the memtrace code.
      
      Fixes: 9d5171a8 ("powerpc/powernv: Enable removal of memory for in memory tracing")
      Cc: stable@vger.kernel.org # v4.14+
      Signed-off-by: NBalbir Singh <bsingharora@gmail.com>
      Acked-by: NReza Arbab <arbab@linux.ibm.com>
      Reviewed-by: NRashmica Gupta <rashmica.g@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      fb5924fd
  7. 21 4月, 2018 1 次提交
  8. 19 4月, 2018 2 次提交
    • M
      powerpc/kvm: Fix lockups when running KVM guests on Power8 · 56376c58
      Michael Ellerman 提交于
      When running KVM guests on Power8 we can see a lockup where one CPU
      stops responding. This often leads to a message such as:
      
        watchdog: CPU 136 detected hard LOCKUP on other CPUs 72
        Task dump for CPU 72:
        qemu-system-ppc R  running task    10560 20917  20908 0x00040004
      
      And then backtraces on other CPUs, such as:
      
        Task dump for CPU 48:
        ksmd            R  running task    10032  1519      2 0x00000804
        Call Trace:
          ...
          --- interrupt: 901 at smp_call_function_many+0x3c8/0x460
              LR = smp_call_function_many+0x37c/0x460
          pmdp_invalidate+0x100/0x1b0
          __split_huge_pmd+0x52c/0xdb0
          try_to_unmap_one+0x764/0x8b0
          rmap_walk_anon+0x15c/0x370
          try_to_unmap+0xb4/0x170
          split_huge_page_to_list+0x148/0xa30
          try_to_merge_one_page+0xc8/0x990
          try_to_merge_with_ksm_page+0x74/0xf0
          ksm_scan_thread+0x10ec/0x1ac0
          kthread+0x160/0x1a0
          ret_from_kernel_thread+0x5c/0x78
      
      This is caused by commit 8c1c7fb0 ("powerpc/64s/idle: avoid sync
      for KVM state when waking from idle"), which added a check in
      pnv_powersave_wakeup() to see if the kvm_hstate.hwthread_state is
      already set to KVM_HWTHREAD_IN_KERNEL, and if so to skip the store and
      test of kvm_hstate.hwthread_req.
      
      The problem is that the primary does not set KVM_HWTHREAD_IN_KVM when
      entering the guest, so it can then come out to cede with
      KVM_HWTHREAD_IN_KERNEL set. It can then go idle in kvm_do_nap after
      setting hwthread_req to 1, but because hwthread_state is still
      KVM_HWTHREAD_IN_KERNEL we will skip the test of hwthread_req when we
      wake up from idle and won't go to kvm_start_guest. From there the
      thread will return somewhere garbage and crash.
      
      Fix it by skipping the store of hwthread_state, but not the test of
      hwthread_req, when coming out of idle. It's OK to skip the sync in
      that case because hwthread_req will have been set on the same thread,
      so there is no synchronisation required.
      
      Fixes: 8c1c7fb0 ("powerpc/64s/idle: avoid sync for KVM state when waking from idle")
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      56376c58
    • M
      powerpc/eeh: Fix enabling bridge MMIO windows · 13a83eac
      Michael Neuling 提交于
      On boot we save the configuration space of PCIe bridges. We do this so
      when we get an EEH event and everything gets reset that we can restore
      them.
      
      Unfortunately we save this state before we've enabled the MMIO space
      on the bridges. Hence if we have to reset the bridge when we come back
      MMIO is not enabled and we end up taking an PE freeze when the driver
      starts accessing again.
      
      This patch forces the memory/MMIO and bus mastering on when restoring
      bridges on EEH. Ideally we'd do this correctly by saving the
      configuration space writes later, but that will have to come later in
      a larger EEH rewrite. For now we have this simple fix.
      
      The original bug can be triggered on a boston machine by doing:
        echo 0x8000000000000000 > /sys/kernel/debug/powerpc/PCI0001/err_injct_outbound
      On boston, this PHB has a PCIe switch on it.  Without this patch,
      you'll see two EEH events, 1 expected and 1 the failure we are fixing
      here. The second EEH event causes the anything under the PHB to
      disappear (i.e. the i40e eth).
      
      With this patch, only 1 EEH event occurs and devices properly recover.
      
      Fixes: 652defed ("powerpc/eeh: Check PCIe link after reset")
      Cc: stable@vger.kernel.org # v3.11+
      Reported-by: NPridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
      Signed-off-by: NMichael Neuling <mikey@neuling.org>
      Acked-by: NRussell Currey <ruscur@russell.cc>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      13a83eac
  9. 18 4月, 2018 1 次提交
  10. 17 4月, 2018 1 次提交
  11. 16 4月, 2018 1 次提交
    • M
      powerpc/lib: Fix off-by-one in alternate feature patching · b8858581
      Michael Ellerman 提交于
      When we patch an alternate feature section, we have to adjust any
      relative branches that branch out of the alternate section.
      
      But currently we have a bug if we have a branch that points to past
      the last instruction of the alternate section, eg:
      
        FTR_SECTION_ELSE
        1:     b       2f
               or      6,6,6
        2:
        ALT_FTR_SECTION_END(...)
               nop
      
      This will result in a relative branch at 1 with a target that equals
      the end of the alternate section.
      
      That branch does not need adjusting when it's moved to the non-else
      location. Currently we do adjust it, resulting in a branch that goes
      off into the link-time location of the else section, which is junk.
      
      The fix is to not patch branches that have a target == end of the
      alternate section.
      
      Fixes: d20fe50a ("KVM: PPC: Book3S HV: Branch inside feature section")
      Fixes: 9b1a735d ("powerpc: Add logic to patch alternative feature sections")
      Cc: stable@vger.kernel.org # v2.6.27+
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      b8858581
  12. 14 4月, 2018 1 次提交
    • P
      kernel/kexec_file.c: allow archs to set purgatory load address · 3be3f61d
      Philipp Rudo 提交于
      For s390 new kernels are loaded to fixed addresses in memory before they
      are booted.  With the current code this is a problem as it assumes the
      kernel will be loaded to an 'arbitrary' address.  In particular,
      kexec_locate_mem_hole searches for a large enough memory region and sets
      the load address (kexec_bufer->mem) to it.
      
      Luckily there is a simple workaround for this problem.  By returning 1
      in arch_kexec_walk_mem, kexec_locate_mem_hole is turned off.  This
      allows the architecture to set kbuf->mem by hand.  While the trick works
      fine for the kernel it does not for the purgatory as here the
      architectures don't have access to its kexec_buffer.
      
      Give architectures access to the purgatories kexec_buffer by changing
      kexec_load_purgatory to take a pointer to it.  With this change
      architectures have access to the buffer and can edit it as they need.
      
      A nice side effect of this change is that we can get rid of the
      purgatory_info->purgatory_load_address field.  As now the information
      stored there can directly be accessed from kbuf->mem.
      
      Link: http://lkml.kernel.org/r/20180321112751.22196-11-prudo@linux.vnet.ibm.comSigned-off-by: NPhilipp Rudo <prudo@linux.vnet.ibm.com>
      Reviewed-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Acked-by: NDave Young <dyoung@redhat.com>
      Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3be3f61d
新手
引导
客服 返回
顶部