1. 27 Feb, 2016 1 commit
  2. 25 Feb, 2016 1 commit
  3. 24 Feb, 2016 5 commits
  4. 22 Feb, 2016 6 commits
  5. 17 Feb, 2016 7 commits
  6. 15 Feb, 2016 4 commits
    • Aneesh Kumar K.V's avatar
      powerpc/mm: Fix Multi hit ERAT cause by recent THP update · c777e2a8
      Aneesh Kumar K.V authored
      With ppc64 we use the deposited pgtable_t to store the hash pte slot
      information. We should not withdraw the deposited pgtable_t without
      marking the pmd none. This ensure that low level hash fault handling
      will skip this huge pte and we will handle them at upper levels.
      
      Recent change to pmd splitting changed the above in order to handle the
      race between pmd split and exit_mmap. The race is explained below.
      
      Consider following race:
      
      		CPU0				CPU1
      shrink_page_list()
        add_to_swap()
          split_huge_page_to_list()
            __split_huge_pmd_locked()
              pmdp_huge_clear_flush_notify()
      	// pmd_none() == true
      					exit_mmap()
      					  unmap_vmas()
      					    zap_pmd_range()
      					      // no action on pmd since pmd_none() == true
      	pmd_populate()
      
      As result the THP will not be freed. The leak is detected by check_mm():
      
      	BUG: Bad rss-counter state mm:ffff880058d2e580 idx:1 val:512
      
      The above required us to not mark pmd none during a pmd split.
      
      The fix for ppc is to clear the huge pte of _PAGE_USER, so that low
      level fault handling code skip this pte. At higher level we do take ptl
      lock. That should serialze us against the pmd split. Once the lock is
      acquired we do check the pmd again using pmd_same. That should always
      return false for us and hence we should retry the access. We do the
      pmd_same check in all case after taking plt with
      THP (do_huge_pmd_wp_page, do_huge_pmd_numa_page and
      huge_pmd_set_accessed)
      
      Also make sure we wait for irq disable section in other cpus to finish
      before flipping a huge pte entry with a regular pmd entry. Code paths
      like find_linux_pte_or_hugepte depend on irq disable to get
      a stable pte_t pointer. A parallel thp split need to make sure we
      don't convert a pmd pte to a regular pmd entry without waiting for the
      irq disable section to finish.
      
      Fixes: eef1b3ba ("thp: implement split_huge_pmd()")
      Acked-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Signed-off-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      c777e2a8
    • Gavin Shan's avatar
      powerpc/powernv: Fix stale PE primary bus · 1bc74f1c
      Gavin Shan authored
      When PCI bus is unplugged during full hotplug for EEH recovery,
      the platform PE instance (struct pnv_ioda_pe) isn't released and
      it dereferences the stale PCI bus that has been released. It leads
      to kernel crash when referring to the stale PCI bus.
      
      This fixes the issue by correcting the PE's primary bus when it's
      oneline at plugging time, in pnv_pci_dma_bus_setup() which is to
      be called by pcibios_fixup_bus().
      
      Cc: stable@vger.kernel.org # v4.1+
      Reported-by: default avatarAndrew Donnellan <andrew.donnellan@au1.ibm.com>
      Reported-by: default avatarPradipta Ghosh <pradghos@in.ibm.com>
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Tested-by: default avatarAndrew Donnellan <andrew.donnellan@au1.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      1bc74f1c
    • Gavin Shan's avatar
      powerpc/eeh: Fix stale cached primary bus · 05ba75f8
      Gavin Shan authored
      When PE is created, its primary bus is cached to pe->bus. At later
      point, the cached primary bus is returned from eeh_pe_bus_get().
      However, we could get stale cached primary bus and run into kernel
      crash in one case: full hotplug as part of fenced PHB error recovery
      releases all PCI busses under the PHB at unplugging time and recreate
      them at plugging time. pe->bus is still dereferencing the PCI bus
      that was released.
      
      This adds another PE flag (EEH_PE_PRI_BUS) to represent the validity
      of pe->bus. pe->bus is updated when its first child EEH device is
      online and the flag is set. Before unplugging in full hotplug for
      error recovery, the flag is cleared.
      
      Fixes: 8cdb2833 ("powerpc/eeh: Trace PCI bus from PE")
      Cc: stable@vger.kernel.org #v3.11+
      Reported-by: default avatarAndrew Donnellan <andrew.donnellan@au1.ibm.com>
      Reported-by: default avatarPradipta Ghosh <pradghos@in.ibm.com>
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Tested-by: default avatarAndrew Donnellan <andrew.donnellan@au1.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      05ba75f8
    • Denis Kirjanov's avatar
      powerpc/pseries: Don't trace hcalls on offline CPUs · 126df08c
      Denis Kirjanov authored
      If a cpu is hotplugged while the hcall trace points are active, it's
      possible to hit a warning from RCU due to the trace points calling into
      RCU from an offline cpu, eg:
      
        RCU used illegally from offline CPU!
        rcu_scheduler_active = 1, debug_locks = 1
      
      Make the hypervisor tracepoints conditional by using
      TRACE_EVENT_FN_COND.
      Acked-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarDenis Kirjanov <kda@linux-powerpc.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      126df08c
  7. 10 Feb, 2016 8 commits
  8. 09 Feb, 2016 3 commits
  9. 08 Feb, 2016 4 commits
  10. 07 Feb, 2016 1 commit