1. 30 5月, 2018 1 次提交
    • U
      s390/net: add pnetid support · b6ef86e9
      Ursula Braun 提交于
      s390 hardware supports the definition of a so-call Physical NETwork
      IDentifier (short PNETID) per network device port. These PNETIDS
      can be used to identify network devices that are attached to the same
      physical network (broadcast domain).
      
      This patch provides the interface to extract the PNETID of a port of
      a device attached to the ccw-bus or pci-bus.
      
      Parts of this patch are based on an initial implementation by
      Thomas Richter.
      Signed-off-by: NUrsula Braun <ubraun@linux.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      b6ef86e9
  2. 23 5月, 2018 3 次提交
  3. 09 5月, 2018 7 次提交
  4. 08 5月, 2018 7 次提交
  5. 07 5月, 2018 3 次提交
  6. 27 4月, 2018 2 次提交
    • S
      s390/kexec_file: add declaration of purgatory related globals · 598d7656
      Sebastian Ott 提交于
      Fix the following sparse complaints:
      
      arch/s390/purgatory/purgatory.c:18:5: warning: symbol 'kernel_entry' was not declared. Should it be static?
      arch/s390/purgatory/purgatory.c:19:5: warning: symbol 'kernel_type' was not declared. Should it be static?
      arch/s390/purgatory/purgatory.c:21:5: warning: symbol 'crash_start' was not declared. Should it be static?
      arch/s390/purgatory/purgatory.c:22:5: warning: symbol 'crash_size' was not declared. Should it be static?
      Signed-off-by: NSebastian Ott <sebott@linux.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      598d7656
    • S
      s390: update defconfigs · d14be68f
      Sebastian Ott 提交于
      Change the following to y:
      
      arch/s390/configs/performance_defconfig:262:warning: symbol value 'm' invalid for NF_TABLES_IPV4
      arch/s390/configs/performance_defconfig:264:warning: symbol value 'm' invalid for NF_TABLES_ARP
      arch/s390/configs/performance_defconfig:285:warning: symbol value 'm' invalid for NF_TABLES_IPV6
      arch/s390/configs/performance_defconfig:306:warning: symbol value 'm' invalid for NF_TABLES_BRIDGE
      Signed-off-by: NSebastian Ott <sebott@linux.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      d14be68f
  7. 25 4月, 2018 4 次提交
  8. 23 4月, 2018 4 次提交
  9. 21 4月, 2018 2 次提交
  10. 20 4月, 2018 3 次提交
  11. 19 4月, 2018 4 次提交
    • 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
    • M
      MIPS: uaccess: Add micromips clobbers to bzero invocation · b3d7e55c
      Matt Redfearn 提交于
      The micromips implementation of bzero additionally clobbers registers t7
      & t8. Specify this in the clobbers list when invoking bzero.
      
      Fixes: 26c5e07d ("MIPS: microMIPS: Optimise 'memset' core library function.")
      Reported-by: NJames Hogan <jhogan@kernel.org>
      Signed-off-by: NMatt Redfearn <matt.redfearn@mips.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: <stable@vger.kernel.org> # 3.10+
      Patchwork: https://patchwork.linux-mips.org/patch/19110/Signed-off-by: NJames Hogan <jhogan@kernel.org>
      b3d7e55c
    • M
      MIPS: memset.S: Fix clobber of v1 in last_fixup · c96eebf0
      Matt Redfearn 提交于
      The label .Llast_fixup\@ is jumped to on page fault within the final
      byte set loop of memset (on < MIPSR6 architectures). For some reason, in
      this fault handler, the v1 register is randomly set to a2 & STORMASK.
      This clobbers v1 for the calling function. This can be observed with the
      following test code:
      
      static int __init __attribute__((optimize("O0"))) test_clear_user(void)
      {
        register int t asm("v1");
        char *test;
        int j, k;
      
        pr_info("\n\n\nTesting clear_user\n");
        test = vmalloc(PAGE_SIZE);
      
        for (j = 256; j < 512; j++) {
          t = 0xa5a5a5a5;
          if ((k = clear_user(test + PAGE_SIZE - 256, j)) != j - 256) {
              pr_err("clear_user (%px %d) returned %d\n", test + PAGE_SIZE - 256, j, k);
          }
          if (t != 0xa5a5a5a5) {
             pr_err("v1 was clobbered to 0x%x!\n", t);
          }
        }
      
        return 0;
      }
      late_initcall(test_clear_user);
      
      Which demonstrates that v1 is indeed clobbered (MIPS64):
      
      Testing clear_user
      v1 was clobbered to 0x1!
      v1 was clobbered to 0x2!
      v1 was clobbered to 0x3!
      v1 was clobbered to 0x4!
      v1 was clobbered to 0x5!
      v1 was clobbered to 0x6!
      v1 was clobbered to 0x7!
      
      Since the number of bytes that could not be set is already contained in
      a2, the andi placing a value in v1 is not necessary and actively
      harmful in clobbering v1.
      Reported-by: NJames Hogan <jhogan@kernel.org>
      Signed-off-by: NMatt Redfearn <matt.redfearn@mips.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: stable@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/19109/Signed-off-by: NJames Hogan <jhogan@kernel.org>
      c96eebf0