1. 11 Oct, 2016 4 commits
    • Paul Mackerras's avatar
      powerpc/64: Fix incorrect return value from __copy_tofrom_user · 1a34439e
      Paul Mackerras authored
      Debugging a data corruption issue with virtio-net/vhost-net led to
      the observation that __copy_tofrom_user was occasionally returning
      a value 16 larger than it should.  Since the return value from
      __copy_tofrom_user is the number of bytes not copied, this means
      that __copy_tofrom_user can occasionally return a value larger
      than the number of bytes it was asked to copy.  In turn this can
      cause higher-level copy functions such as copy_page_to_iter_iovec
      to corrupt memory by copying data into the wrong memory locations.
      
      It turns out that the failing case involves a fault on the store
      at label 79, and at that point the first unmodified byte of the
      destination is at R3 + 16.  Consequently the exception handler
      for that store needs to add 16 to R3 before using it to work out
      how many bytes were not copied, but in this one case it was not
      adding the offset to R3.  To fix it, this moves the label 179 to
      the point where we add 16 to R3.  I have checked manually all the
      exception handlers for the loads and stores in this code and the
      rest of them are correct (it would be excellent to have an
      automated test of all the exception cases).
      
      This bug has been present since this code was initially
      committed in May 2002 to Linux version 2.5.20.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      1a34439e
    • Nicholas Piggin's avatar
      powerpc/64s: Fix power4_fixup_nap placement · 7c8cb4b5
      Nicholas Piggin authored
      power4_fixup_nap is called from the "common" handlers, not the virt/real
      handlers, therefore it should itself be a common handler. Placing it
      down in the trampoline space caused it to go out of reach of its
      callers, requiring a trampoline inserted at the start of the text
      section, which breaks the fixed section address calculations.
      
      Fixes: da2bc464 ("powerpc/64s: Add new exception vector macros")
      Reported-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      7c8cb4b5
    • Laurent Dufour's avatar
      powerpc/pseries: Fix stack corruption in htpe code · 05af40e8
      Laurent Dufour authored
      This commit fixes a stack corruption in the pseries specific code dealing
      with the huge pages.
      
      In __pSeries_lpar_hugepage_invalidate() the buffer used to pass arguments
      to the hypervisor is not large enough. This leads to a stack corruption
      where a previously saved register could be corrupted leading to unexpected
      result in the caller, like the following panic:
      
        Oops: Kernel access of bad area, sig: 11 [#1]
        SMP NR_CPUS=2048 NUMA pSeries
        Modules linked in: virtio_balloon ip_tables x_tables autofs4
        virtio_blk 8139too virtio_pci virtio_ring 8139cp virtio
        CPU: 11 PID: 1916 Comm: mmstress Not tainted 4.8.0 #76
        task: c000000005394880 task.stack: c000000005570000
        NIP: c00000000027bf6c LR: c00000000027bf64 CTR: 0000000000000000
        REGS: c000000005573820 TRAP: 0300   Not tainted  (4.8.0)
        MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE>  CR: 84822884  XER: 20000000
        CFAR: c00000000010a924 DAR: 420000000014e5e0 DSISR: 40000000 SOFTE: 1
        GPR00: c00000000027bf64 c000000005573aa0 c000000000e02800 c000000004447964
        GPR04: c00000000404de18 c000000004d38810 00000000042100f5 00000000f5002104
        GPR08: e0000000f5002104 0000000000000001 042100f5000000e0 00000000042100f5
        GPR12: 0000000000002200 c00000000fe02c00 c00000000404de18 0000000000000000
        GPR16: c1ffffffffffe7ff 00003fff62000000 420000000014e5e0 00003fff63000000
        GPR20: 0008000000000000 c0000000f7014800 0405e600000000e0 0000000000010000
        GPR24: c000000004d38810 c000000004447c10 c00000000404de18 c000000004447964
        GPR28: c000000005573b10 c000000004d38810 00003fff62000000 420000000014e5e0
        NIP [c00000000027bf6c] zap_huge_pmd+0x4c/0x470
        LR [c00000000027bf64] zap_huge_pmd+0x44/0x470
        Call Trace:
        [c000000005573aa0] [c00000000027bf64] zap_huge_pmd+0x44/0x470 (unreliable)
        [c000000005573af0] [c00000000022bbd8] unmap_page_range+0xcf8/0xed0
        [c000000005573c30] [c00000000022c2d4] unmap_vmas+0x84/0x120
        [c000000005573c80] [c000000000235448] unmap_region+0xd8/0x1b0
        [c000000005573d80] [c0000000002378f0] do_munmap+0x2d0/0x4c0
        [c000000005573df0] [c000000000237be4] SyS_munmap+0x64/0xb0
        [c000000005573e30] [c000000000009560] system_call+0x38/0x108
        Instruction dump:
        fbe1fff8 fb81ffe0 7c7f1b78 7ca32b78 7cbd2b78 f8010010 7c9a2378 f821ffb1
        7cde3378 4bfffea9 7c7b1b79 41820298 <e87f0000> 48000130 7fa5eb78 7fc4f378
      
      Most of the time, the bug is surfacing in a caller up in the stack from
      __pSeries_lpar_hugepage_invalidate() which is quite confusing.
      
      This bug is pending since v3.11 but was hidden if a caller of the
      caller of __pSeries_lpar_hugepage_invalidate() has pushed the corruped
      register (r18 in this case) in the stack and is not using it until
      restoring it. GCC 6.2.0 seems to raise it more frequently.
      
      This commit also change the definition of the parameter buffer in
      pSeries_lpar_flush_hash_range() to rely on the global define
      PLPAR_HCALL9_BUFSIZE (no functional change here).
      
      Fixes: 1a527286 ("powerpc: Optimize hugepage invalidate")
      Cc: stable@vger.kernel.org # v3.11+
      Signed-off-by: default avatarLaurent Dufour <ldufour@linux.vnet.ibm.com>
      Reviewed-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Acked-by: default avatarBalbir Singh <bsingharora@gmail.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      05af40e8
    • Michael Ellerman's avatar
      Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux into next · 065397a9
      Michael Ellerman authored
      Freescale updates from Scott:
      
      "Highlights include qbman support (a prerequisite for datapath drivers
      such as ethernet), a PCI DMA fix+improvement, reset handler changes, more
      8xx optimizations, and some cleanups and fixes."
      065397a9
  2. 06 Oct, 2016 5 commits
  3. 04 Oct, 2016 31 commits