1. 06 12月, 2016 4 次提交
  2. 28 11月, 2016 3 次提交
  3. 27 11月, 2016 8 次提交
  4. 26 11月, 2016 22 次提交
  5. 25 11月, 2016 3 次提交
    • J
      parisc: Also flush data TLB in flush_icache_page_asm · 5035b230
      John David Anglin 提交于
      This is the second issue I noticed in reviewing the parisc TLB code.
      
      The fic instruction may use either the instruction or data TLB in
      flushing the instruction cache.  Thus, on machines with a split TLB, we
      should also flush the data TLB after setting up the temporary alias
      registers.
      
      Although this has no functional impact, I changed the pdtlb and pitlb
      instructions to consistently use the index register %r0.  These
      instructions do not support integer displacements.
      
      Tested on rp3440 and c8000.
      Signed-off-by: NJohn David Anglin  <dave.anglin@bell.net>
      Cc: <stable@vger.kernel.org> # v3.16+
      Signed-off-by: NHelge Deller <deller@gmx.de>
      5035b230
    • J
      parisc: Fix race in pci-dma.c · c0452fb9
      John David Anglin 提交于
      We are still troubled by occasional random segmentation faults and
      memory memory corruption on SMP machines.  The causes quite a few
      package builds to fail on the Debian buildd machines for parisc.  When
      gcc-6 failed to build three times in a row, I looked again at the TLB
      related code.  I found a couple of issues.  This is the first.
      
      In general, we need to ensure page table updates and corresponding TLB
      purges are atomic.  The attached patch fixes an instance in pci-dma.c
      where the page table update was not guarded by the TLB lock.
      
      Tested on rp3440 and c8000.  So far, no further random segmentation
      faults have been observed.
      Signed-off-by: NJohn David Anglin  <dave.anglin@bell.net>
      Cc: <stable@vger.kernel.org> # v3.16+
      Signed-off-by: NHelge Deller <deller@gmx.de>
      c0452fb9
    • H
      parisc: Switch to generic sched_clock implementation · 43b1f6ab
      Helge Deller 提交于
      Drop the open-coded sched_clock() function and replace it by the provided
      GENERIC_SCHED_CLOCK implementation.  We have seen quite some hung tasks in the
      past, which seem to be fixed by this patch.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      Cc: <stable@vger.kernel.org> # v4.7+
      Signed-off-by: NHelge Deller <deller@gmx.de>
      43b1f6ab