1. 21 Nov, 2018 3 commits
  2. 13 Nov, 2018 2 commits
    • Helge Deller's avatar
      parisc: Fix map_pages() to not overwrite existing pte entries · d35b161d
      Helge Deller authored
      commit 3c229b3f2dd8133f61bb81d3cb018be92f4bba39 upstream.
      
      Fix a long-existing small nasty bug in the map_pages() implementation which
      leads to overwriting already written pte entries with zero, *if* map_pages() is
      called a second time with an end address which isn't aligned on a pmd boundry.
      This happens for example if we want to remap only the text segment read/write
      in order to run alternative patching on the code. Exiting the loop when we
      reach the end address fixes this.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d35b161d
    • John David Anglin's avatar
      parisc: Fix address in HPMC IVA · 662d2aef
      John David Anglin authored
      commit 1138b6718ff74d2a934459643e3754423d23b5e2 upstream.
      
      Helge noticed that the address of the os_hpmc handler was not being
      correctly calculated in the hpmc macro.  As a result, PDCE_CHECK would
      fail to call os_hpmc:
      
      <Cpu2> e800009802e00000  0000000000000000  CC_ERR_CHECK_HPMC
      <Cpu2> 37000f7302e00000  8040004000000000  CC_ERR_CPU_CHECK_SUMMARY
      <Cpu2> f600105e02e00000  fffffff0f0c00000  CC_MC_HPMC_MONARCH_SELECTED
      <Cpu2> 140003b202e00000  000000000000000b  CC_ERR_HPMC_STATE_ENTRY
      <Cpu2> 5600100b02e00000  00000000000001a0  CC_MC_OS_HPMC_LEN_ERR
      <Cpu2> 5600106402e00000  fffffff0f0438e70  CC_MC_BR_TO_OS_HPMC_FAILED
      <Cpu2> e800009802e00000  0000000000000000  CC_ERR_CHECK_HPMC
      <Cpu2> 37000f7302e00000  8040004000000000  CC_ERR_CPU_CHECK_SUMMARY
      <Cpu2> 4000109f02e00000  0000000000000000  CC_MC_HPMC_INITIATED
      <Cpu2> 4000101902e00000  0000000000000000  CC_MC_MULTIPLE_HPMCS
      <Cpu2> 030010d502e00000  0000000000000000  CC_CPU_STOP
      
      The address problem can be seen by dumping the fault vector:
      
      0000000040159000 <fault_vector_20>:
          40159000:   63 6f 77 73     stb r15,-2447(dp)
          40159004:   20 63 61 6e     ldil L%b747000,r3
          40159008:   20 66 6c 79     ldil L%-1c3b3000,r3
              ...
          40159020:   08 00 02 40     nop
          40159024:   20 6e 60 02     ldil L%15d000,r3
          40159028:   34 63 00 00     ldo 0(r3),r3
          4015902c:   e8 60 c0 02     bv,n r0(r3)
          40159030:   08 00 02 40     nop
          40159034:   00 00 00 00     break 0,0
          40159038:   c0 00 70 00     bb,*< r0,sar,40159840 <fault_vector_20+0x840>
          4015903c:   00 00 00 00     break 0,0
      
      Location 40159038 should contain the physical address of os_hpmc:
      
      000000004015d000 <os_hpmc>:
          4015d000:   08 1a 02 43     copy r26,r3
          4015d004:   01 c0 08 a4     mfctl iva,r4
          4015d008:   48 85 00 68     ldw 34(r4),r5
      
      This patch moves the address setup into initialize_ivt to resolve the
      above problem.  I tested the change by dumping the HPMC entry after setup:
      
      0000000040209020:  8000240
      0000000040209024: 206a2004
      0000000040209028: 34630ac0
      000000004020902c: e860c002
      0000000040209030:  8000240
      0000000040209034: 1bdddce6
      0000000040209038:   15d000
      000000004020903c:      1a0
      Signed-off-by: default avatarJohn David Anglin <dave.anglin@bell.net>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      662d2aef
  3. 24 Aug, 2018 2 commits
  4. 15 Aug, 2018 2 commits
  5. 19 May, 2018 1 commit
    • Jiri Slaby's avatar
      futex: Remove duplicated code and fix undefined behaviour · 81da9f87
      Jiri Slaby authored
      commit 30d6e0a4 upstream.
      
      There is code duplicated over all architecture's headers for
      futex_atomic_op_inuser. Namely op decoding, access_ok check for uaddr,
      and comparison of the result.
      
      Remove this duplication and leave up to the arches only the needed
      assembly which is now in arch_futex_atomic_op_inuser.
      
      This effectively distributes the Will Deacon's arm64 fix for undefined
      behaviour reported by UBSAN to all architectures. The fix was done in
      commit 5f16a046 (arm64: futex: Fix undefined behaviour with
      FUTEX_OP_OPARG_SHIFT usage). Look there for an example dump.
      
      And as suggested by Thomas, check for negative oparg too, because it was
      also reported to cause undefined behaviour report.
      
      Note that s390 removed access_ok check in d12a2970 ("s390/uaccess:
      remove pointless access_ok() checks") as access_ok there returns true.
      We introduce it back to the helper for the sake of simplicity (it gets
      optimized away anyway).
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> [s390]
      Acked-by: Chris Metcalf <cmetcalf@mellanox.com> [for tile]
      Reviewed-by: default avatarDarren Hart (VMware) <dvhart@infradead.org>
      Reviewed-by: Will Deacon <will.deacon@arm.com> [core/arm64]
      Cc: linux-mips@linux-mips.org
      Cc: Rich Felker <dalias@libc.org>
      Cc: linux-ia64@vger.kernel.org
      Cc: linux-sh@vger.kernel.org
      Cc: peterz@infradead.org
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: sparclinux@vger.kernel.org
      Cc: Jonas Bonn <jonas@southpole.se>
      Cc: linux-s390@vger.kernel.org
      Cc: linux-arch@vger.kernel.org
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: linux-hexagon@vger.kernel.org
      Cc: Helge Deller <deller@gmx.de>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: linux-snps-arc@lists.infradead.org
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: linux-xtensa@linux-xtensa.org
      Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
      Cc: openrisc@lists.librecores.org
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Stafford Horne <shorne@gmail.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: linux-parisc@vger.kernel.org
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Richard Kuo <rkuo@codeaurora.org>
      Cc: linux-alpha@vger.kernel.org
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: "David S. Miller" <davem@davemloft.net>
      Link: http://lkml.kernel.org/r/20170824073105.3901-1-jslaby@suse.cz
      Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      81da9f87
  6. 20 Apr, 2018 1 commit
    • Helge Deller's avatar
      parisc: Fix out of array access in match_pci_device() · 68401e8b
      Helge Deller authored
      commit 615b2665fd20c327b631ff1e79426775de748094 upstream.
      
      As found by the ubsan checker, the value of the 'index' variable can be
      out of range for the bc[] array:
      
      UBSAN: Undefined behaviour in arch/parisc/kernel/drivers.c:655:21
      index 6 is out of range for type 'char [6]'
      Backtrace:
       [<104fa850>] __ubsan_handle_out_of_bounds+0x68/0x80
       [<1019d83c>] check_parent+0xc0/0x170
       [<1019d91c>] descend_children+0x30/0x6c
       [<1059e164>] device_for_each_child+0x60/0x98
       [<1019cd54>] parse_tree_node+0x40/0x54
       [<1019d86c>] check_parent+0xf0/0x170
       [<1019d91c>] descend_children+0x30/0x6c
       [<1059e164>] device_for_each_child+0x60/0x98
       [<1019d938>] descend_children+0x4c/0x6c
       [<1059e164>] device_for_each_child+0x60/0x98
       [<1019cd54>] parse_tree_node+0x40/0x54
       [<1019cffc>] hwpath_to_device+0xa4/0xc4
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      68401e8b
  7. 22 Mar, 2018 1 commit
    • John David Anglin's avatar
      parisc: Handle case where flush_cache_range is called with no context · 8f6cfbea
      John David Anglin authored
      commit 9ef0f88f upstream.
      
      Just when I had decided that flush_cache_range() was always called with
      a valid context, Helge reported two cases where the
      "BUG_ON(!vma->vm_mm->context);" was hit on the phantom buildd:
      
       kernel BUG at /mnt/sdb6/linux/linux-4.15.4/arch/parisc/kernel/cache.c:587!
       CPU: 1 PID: 3254 Comm: kworker/1:2 Tainted: G D 4.15.0-1-parisc64-smp #1 Debian 4.15.4-1+b1
       Workqueue: events free_ioctx
        IAOQ[0]: flush_cache_range+0x164/0x168
        IAOQ[1]: flush_cache_page+0x0/0x1c8
        RP(r2): unmap_page_range+0xae8/0xb88
       Backtrace:
        [<00000000404a6980>] unmap_page_range+0xae8/0xb88
        [<00000000404a6ae0>] unmap_single_vma+0xc0/0x188
        [<00000000404a6cdc>] zap_page_range_single+0x134/0x1f8
        [<00000000404a702c>] unmap_mapping_range+0x1cc/0x208
        [<0000000040461518>] truncate_pagecache+0x98/0x108
        [<0000000040461624>] truncate_setsize+0x9c/0xb8
        [<00000000405d7f30>] put_aio_ring_file+0x80/0x100
        [<00000000405d803c>] aio_free_ring+0x8c/0x290
        [<00000000405d82c0>] free_ioctx+0x80/0x180
        [<0000000040284e6c>] process_one_work+0x21c/0x668
        [<00000000402854c4>] worker_thread+0x20c/0x778
        [<0000000040291d44>] kthread+0x2d4/0x2e0
        [<0000000040204020>] end_fault_vector+0x20/0xc0
      
      This indicates that we need to handle the no context case in
      flush_cache_range() as we do in flush_cache_mm().
      
      In thinking about this, I realized that we don't need to flush the TLB
      when there is no context.  So, I added context checks to the large flush
      cases in flush_cache_mm() and flush_cache_range().  The large flush case
      occurs frequently in flush_cache_mm() and the change should improve fork
      performance.
      
      The v2 version of this change removes the BUG_ON from flush_cache_page()
      by skipping the TLB flush when there is no context.  I also added code
      to flush the TLB in flush_cache_mm() and flush_cache_range() when we
      have a context that's not current.  Now all three routines handle TLB
      flushes in a similar manner.
      Signed-off-by: default avatarJohn David Anglin <dave.anglin@bell.net>
      Cc: stable@vger.kernel.org # 4.9+
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8f6cfbea
  8. 11 Mar, 2018 1 commit
    • John David Anglin's avatar
      parisc: Fix ordering of cache and TLB flushes · 12efc915
      John David Anglin authored
      commit 0adb24e0 upstream.
      
      The change to flush_kernel_vmap_range() wasn't sufficient to avoid the
      SMP stalls.  The problem is some drivers call these routines with
      interrupts disabled.  Interrupts need to be enabled for flush_tlb_all()
      and flush_cache_all() to work.  This version adds checks to ensure
      interrupts are not disabled before calling routines that need IPI
      interrupts.  When interrupts are disabled, we now drop into slower code.
      
      The attached change fixes the ordering of cache and TLB flushes in
      several cases.  When we flush the cache using the existing PTE/TLB
      entries, we need to flush the TLB after doing the cache flush.  We don't
      need to do this when we flush the entire instruction and data caches as
      these flushes don't use the existing TLB entries.  The same is true for
      tmpalias region flushes.
      
      The flush_kernel_vmap_range() and invalidate_kernel_vmap_range()
      routines have been updated.
      
      Secondly, we added a new purge_kernel_dcache_range_asm() routine to
      pacache.S and use it in invalidate_kernel_vmap_range().  Nominally,
      purges are faster than flushes as the cache lines don't have to be
      written back to memory.
      
      Hopefully, this is sufficient to resolve the remaining problems due to
      cache speculation.  So far, testing indicates that this is the case.  I
      did work up a patch using tmpalias flushes, but there is a performance
      hit because we need the physical address for each page, and we also need
      to sequence access to the tmpalias flush code.  This increases the
      probability of stalls.
      
      Signed-off-by: John David Anglin <dave.anglin@bell.net>
      Cc: stable@vger.kernel.org # 4.9+
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      12efc915
  9. 10 Jan, 2018 2 commits
  10. 30 Nov, 2017 1 commit
    • John David Anglin's avatar
      parisc: Fix validity check of pointer size argument in new CAS implementation · 03d1bba8
      John David Anglin authored
      commit 05f016d2 upstream.
      
      As noted by Christoph Biedl, passing a pointer size of 4 in the new CAS
      implementation causes a kernel crash.  The attached patch corrects the
      off by one error in the argument validity check.
      
      In reviewing the code, I noticed that we only perform word operations
      with the pointer size argument.  The subi instruction intentionally uses
      a word condition on 64-bit kernels.  Nullification was used instead of a
      cmpib instruction as the branch should never be taken.  The shlw
      pseudo-operation generates a depw,z instruction and it clears the target
      before doing a shift left word deposit.  Thus, we don't need to clip the
      upper 32 bits of this argument on 64-bit kernels.
      
      Tested with a gcc testsuite run with a 64-bit kernel.  The gcc atomic
      code in libgcc is the only direct user of the new CAS implementation
      that I am aware of.
      Signed-off-by: default avatarJohn David Anglin <dave.anglin@bell.net>
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      03d1bba8
  11. 27 Oct, 2017 1 commit
  12. 08 Oct, 2017 1 commit
  13. 11 Aug, 2017 1 commit
    • John David Anglin's avatar
      parisc: Handle vma's whose context is not current in flush_cache_range · 5d23e4f3
      John David Anglin authored
      commit 13d57093 upstream.
      
      In testing James' patch to drivers/parisc/pdc_stable.c, I hit the BUG
      statement in flush_cache_range() during a system shutdown:
      
      kernel BUG at arch/parisc/kernel/cache.c:595!
      CPU: 2 PID: 6532 Comm: kworker/2:0 Not tainted 4.13.0-rc2+ #1
      Workqueue: events free_ioctx
      
       IAOQ[0]: flush_cache_range+0x144/0x148
       IAOQ[1]: flush_cache_page+0x0/0x1a8
       RP(r2): flush_cache_range+0xec/0x148
      Backtrace:
       [<00000000402910ac>] unmap_page_range+0x84/0x880
       [<00000000402918f4>] unmap_single_vma+0x4c/0x60
       [<0000000040291a18>] zap_page_range_single+0x110/0x160
       [<0000000040291c34>] unmap_mapping_range+0x174/0x1a8
       [<000000004026ccd8>] truncate_pagecache+0x50/0xa8
       [<000000004026cd84>] truncate_setsize+0x54/0x70
       [<000000004033d534>] put_aio_ring_file+0x44/0xb0
       [<000000004033d5d8>] aio_free_ring+0x38/0x140
       [<000000004033d714>] free_ioctx+0x34/0xa8
       [<00000000401b0028>] process_one_work+0x1b8/0x4d0
       [<00000000401b04f4>] worker_thread+0x1b4/0x648
       [<00000000401b9128>] kthread+0x1b0/0x208
       [<0000000040150020>] end_fault_vector+0x20/0x28
       [<0000000040639518>] nf_ip_reroute+0x50/0xa8
       [<0000000040638ed0>] nf_ip_route+0x10/0x78
       [<0000000040638c90>] xfrm4_mode_tunnel_input+0x180/0x1f8
      
      CPU: 2 PID: 6532 Comm: kworker/2:0 Not tainted 4.13.0-rc2+ #1
      Workqueue: events free_ioctx
      Backtrace:
       [<0000000040163bf0>] show_stack+0x20/0x38
       [<0000000040688480>] dump_stack+0xa8/0x120
       [<0000000040163dc4>] die_if_kernel+0x19c/0x2b0
       [<0000000040164d0c>] handle_interruption+0xa24/0xa48
      
      This patch modifies flush_cache_range() to handle non current contexts.
      In as much as this occurs infrequently, the simplest approach is to
      flush the entire cache when this happens.
      Signed-off-by: default avatarJohn David Anglin <dave.anglin@bell.net>
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5d23e4f3
  14. 07 Aug, 2017 3 commits
  15. 21 Jul, 2017 4 commits
    • Helge Deller's avatar
      parisc/mm: Ensure IRQs are off in switch_mm() · e3d2adaa
      Helge Deller authored
      commit 649aa242 upstream.
      
      This is because of commit f98db601 ("sched/core: Add switch_mm_irqs_off()
      and use it in the scheduler") in which switch_mm_irqs_off() is called by the
      scheduler, vs switch_mm() which is used by use_mm().
      
      This patch lets the parisc code mirror the x86 and powerpc code, ie. it
      disables interrupts in switch_mm(), and optimises the scheduler case by
      defining switch_mm_irqs_off().
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e3d2adaa
    • Thomas Bogendoerfer's avatar
      parisc: DMA API: return error instead of BUG_ON for dma ops on non dma devs · 8ed89cfc
      Thomas Bogendoerfer authored
      commit 33f9e024 upstream.
      
      Enabling parport pc driver on a B2600 (and probably other 64bit PARISC
      systems) produced following BUG:
      
      CPU: 0 PID: 1 Comm: swapper Not tainted 4.12.0-rc5-30198-g1132d5e7 #156
      task: 000000009e050000 task.stack: 000000009e04c000
      
           YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
      PSW: 00001000000001101111111100001111 Not tainted
      r00-03  000000ff0806ff0f 000000009e04c990 0000000040871b78 000000009e04cac0
      r04-07  0000000040c14de0 ffffffffffffffff 000000009e07f098 000000009d82d200
      r08-11  000000009d82d210 0000000000000378 0000000000000000 0000000040c345e0
      r12-15  0000000000000005 0000000040c345e0 0000000000000000 0000000040c9d5e0
      r16-19  0000000040c345e0 00000000f00001c4 00000000f00001bc 0000000000000061
      r20-23  000000009e04ce28 0000000000000010 0000000000000010 0000000040b89e40
      r24-27  0000000000000003 0000000000ffffff 000000009d82d210 0000000040c14de0
      r28-31  0000000000000000 000000009e04ca90 000000009e04cb40 0000000000000000
      sr00-03  0000000000000000 0000000000000000 0000000000000000 0000000000000000
      sr04-07  0000000000000000 0000000000000000 0000000000000000 0000000000000000
      
      IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000404aece0 00000000404aece4
       IIR: 03ffe01f    ISR: 0000000010340000  IOR: 000001781304cac8
       CPU:        0   CR30: 000000009e04c000 CR31: 00000000e2976de2
       ORIG_R28: 0000000000000200
       IAOQ[0]: sba_dma_supported+0x80/0xd0
       IAOQ[1]: sba_dma_supported+0x84/0xd0
       RP(r2): parport_pc_probe_port+0x178/0x1200
      
      Cause is a call to dma_coerce_mask_and_coherenet in parport_pc_probe_port,
      which PARISC DMA API doesn't handle very nicely. This commit gives back
      DMA_ERROR_CODE for DMA API calls, if device isn't capable of DMA
      transaction.
      Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8ed89cfc
    • Eric Biggers's avatar
      parisc: use compat_sys_keyctl() · bf1e4dc3
      Eric Biggers authored
      commit b0f94efd upstream.
      
      Architectures with a compat syscall table must put compat_sys_keyctl()
      in it, not sys_keyctl().  The parisc architecture was not doing this;
      fix it.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Acked-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bf1e4dc3
    • Helge Deller's avatar
      parisc: Report SIGSEGV instead of SIGBUS when running out of stack · 008a1f27
      Helge Deller authored
      commit 24746231 upstream.
      
      When a process runs out of stack the parisc kernel wrongly faults with SIGBUS
      instead of the expected SIGSEGV signal.
      
      This example shows how the kernel faults:
      do_page_fault() command='a.out' type=15 address=0xfaac2000 in libc-2.24.so[f8308000+16c000]
      trap #15: Data TLB miss fault, vm_start = 0xfa2c2000, vm_end = 0xfaac2000
      
      The vma->vm_end value is the first address which does not belong to the vma, so
      adjust the check to include vma->vm_end to the range for which to send the
      SIGSEGV signal.
      
      This patch unbreaks building the debian libsigsegv package.
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      008a1f27
  16. 24 Jun, 2017 1 commit
    • Hugh Dickins's avatar
      mm: larger stack guard gap, between vmas · cfc0eb40
      Hugh Dickins authored
      commit 1be7107f upstream.
      
      Stack guard page is a useful feature to reduce a risk of stack smashing
      into a different mapping. We have been using a single page gap which
      is sufficient to prevent having stack adjacent to a different mapping.
      But this seems to be insufficient in the light of the stack usage in
      userspace. E.g. glibc uses as large as 64kB alloca() in many commonly
      used functions. Others use constructs liks gid_t buffer[NGROUPS_MAX]
      which is 256kB or stack strings with MAX_ARG_STRLEN.
      
      This will become especially dangerous for suid binaries and the default
      no limit for the stack size limit because those applications can be
      tricked to consume a large portion of the stack and a single glibc call
      could jump over the guard page. These attacks are not theoretical,
      unfortunatelly.
      
      Make those attacks less probable by increasing the stack guard gap
      to 1MB (on systems with 4k pages; but make it depend on the page size
      because systems with larger base pages might cap stack allocations in
      the PAGE_SIZE units) which should cover larger alloca() and VLA stack
      allocations. It is obviously not a full fix because the problem is
      somehow inherent, but it should reduce attack space a lot.
      
      One could argue that the gap size should be configurable from userspace,
      but that can be done later when somebody finds that the new 1MB is wrong
      for some special case applications.  For now, add a kernel command line
      option (stack_guard_gap) to specify the stack gap size (in page units).
      
      Implementation wise, first delete all the old code for stack guard page:
      because although we could get away with accounting one extra page in a
      stack vma, accounting a larger gap can break userspace - case in point,
      a program run with "ulimit -S -v 20000" failed when the 1MB gap was
      counted for RLIMIT_AS; similar problems could come with RLIMIT_MLOCK
      and strict non-overcommit mode.
      
      Instead of keeping gap inside the stack vma, maintain the stack guard
      gap as a gap between vmas: using vm_start_gap() in place of vm_start
      (or vm_end_gap() in place of vm_end if VM_GROWSUP) in just those few
      places which need to respect the gap - mainly arch_get_unmapped_area(),
      and and the vma tree's subtree_gap support for that.
      Original-patch-by: default avatarOleg Nesterov <oleg@redhat.com>
      Original-patch-by: default avatarMichal Hocko <mhocko@suse.com>
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Tested-by: Helge Deller <deller@gmx.de> # parisc
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [wt: backport to 4.11: adjust context]
      [wt: backport to 4.9: adjust context ; kernel doc was not in admin-guide]
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cfc0eb40
  17. 21 Apr, 2017 2 commits
    • Helge Deller's avatar
      parisc: Fix get_user() for 64-bit value on 32-bit kernel · a28acecb
      Helge Deller authored
      commit 3f795cef upstream.
      
      This fixes a bug in which the upper 32-bits of a 64-bit value which is
      read by get_user() was lost on a 32-bit kernel.
      While touching this code, split out pre-loading of %sr2 space register
      and clean up code indent.
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a28acecb
    • Mikulas Patocka's avatar
      parisc: fix bugs in pa_memcpy · 1681bab7
      Mikulas Patocka authored
      commit 409c1b25 upstream.
      
      The patch 554bfece ("parisc: Fix access
      fault handling in pa_memcpy()") reimplements the pa_memcpy function.
      Unfortunatelly, it makes the kernel unbootable. The crash happens in the
      function ide_complete_cmd where memcpy is called with the same source
      and destination address.
      
      This patch fixes a few bugs in pa_memcpy:
      
      * When jumping to .Lcopy_loop_16 for the first time, don't skip the
        instruction "ldi 31,t0" (this bug made the kernel unbootable)
      * Use the COND macro when comparing length, so that the comparison is
        64-bit (a theoretical issue, in case the length is greater than
        0xffffffff)
      * Don't use the COND macro after the "extru" instruction (the PA-RISC
        specification says that the upper 32-bits of extru result are undefined,
        although they are set to zero in practice)
      * Fix exception addresses in .Lcopy16_fault and .Lcopy8_fault
      * Rename .Lcopy_loop_4 to .Lcopy_loop_8 (so that it is consistent with
        .Lcopy8_fault)
      
      Fixes: 554bfece ("parisc: Fix access fault handling in pa_memcpy()")
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1681bab7
  18. 08 Apr, 2017 3 commits
    • Helge Deller's avatar
      parisc: Fix access fault handling in pa_memcpy() · 76343bfb
      Helge Deller authored
      commit 554bfece upstream.
      
      pa_memcpy() is the major memcpy implementation in the parisc kernel which is
      used to do any kind of userspace/kernel memory copies.
      
      Al Viro noticed various bugs in the implementation of pa_mempcy(), most notably
      that in case of faults it may report back to have copied more bytes than it
      actually did.
      
      Fixing those bugs is quite hard in the C-implementation, because the compiler
      is messing around with the registers and we are not guaranteed that specific
      variables are always in the same processor registers. This makes proper fault
      handling complicated.
      
      This patch implements pa_memcpy() in assembler. That way we have correct fault
      handling and adding a 64-bit copy routine was quite easy.
      
      Runtime tested with 32- and 64bit kernels.
      Reported-by: default avatarAl Viro <viro@ZenIV.linux.org.uk>
      Signed-off-by: default avatarJohn David Anglin <dave.anglin@bell.net>
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      76343bfb
    • Helge Deller's avatar
      parisc: Avoid stalled CPU warnings after system shutdown · 99e354a5
      Helge Deller authored
      commit 476e75a4 upstream.
      
      Commit 73580dac ("parisc: Fix system shutdown halt") introduced an endless
      loop for systems which don't provide a software power off function.  But the
      soft lockup detector will detect this and report stalled CPUs after some time.
      Avoid those unwanted warnings by disabling the soft lockup detector.
      
      Fixes: 73580dac ("parisc: Fix system shutdown halt")
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      99e354a5
    • Helge Deller's avatar
      parisc: Clean up fixup routines for get_user()/put_user() · 09b931fc
      Helge Deller authored
      commit d19f5e41 upstream.
      
      Al Viro noticed that userspace accesses via get_user()/put_user() can be
      simplified a lot with regard to usage of the exception handling.
      
      This patch implements a fixup routine for get_user() and put_user() in such
      that the exception handler will automatically load -EFAULT into the register
      %r8 (the error value) in case on a fault on userspace.  Additionally the fixup
      routine will zero the target register on fault in case of a get_user() call.
      The target register is extracted out of the faulting assembly instruction.
      
      This patch brings a few benefits over the old implementation:
      1. Exception handling gets much cleaner, easier and smaller in size.
      2. Helper functions like fixup_get_user_skip_1 (all of fixup.S) can be dropped.
      3. No need to hardcode %r9 as target register for get_user() any longer. This
         helps the compiler register allocator and thus creates less assembler
         statements.
      4. No dependency on the exception_data contents any longer.
      5. Nested faults will be handled cleanly.
      Reported-by: default avatarAl Viro <viro@ZenIV.linux.org.uk>
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      09b931fc
  19. 26 Mar, 2017 2 commits
  20. 01 Feb, 2017 1 commit
  21. 12 Jan, 2017 2 commits
  22. 08 Dec, 2016 1 commit
    • Helge Deller's avatar
      parisc: Fix TLB related boot crash on SMP machines · 24d0492b
      Helge Deller authored
      At bootup we run measurements to calculate the best threshold for when we
      should be using full TLB flushes instead of just flushing a specific amount of
      TLB entries.  This performance test is run over the kernel text segment.
      
      But running this TLB performance test on the kernel text segment turned out to
      crash some SMP machines when the kernel text pages were mapped as huge pages.
      
      To avoid those crashes this patch simply skips this test on some SMP machines
      and calculates an optimal threshold based on the maximum number of available
      TLB entries and number of online CPUs.
      
      On a technical side, this seems to happen:
      The TLB measurement code uses flush_tlb_kernel_range() to flush specific TLB
      entries with a page size of 4k (pdtlb 0(sr1,addr)). On UP systems this purge
      instruction seems to work without problems even if the pages were mapped as
      huge pages.  But on SMP systems the TLB purge instruction is broadcasted to
      other CPUs. Those CPUs then crash the machine because the page size is not as
      expected.  C8000 machines with PA8800/PA8900 CPUs were not affected by this
      problem, because the required cache coherency prohibits to use huge pages at
      all.  Sadly I didn't found any documentation about this behaviour, so this
      finding is purely based on testing with phyiscal SMP machines (A500-44 and
      J5000, both were 2-way boxes).
      
      Cc: <stable@vger.kernel.org> # v3.18+
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      24d0492b
  23. 07 Dec, 2016 2 commits
    • John David Anglin's avatar
      parisc: Remove unnecessary TLB purges from flush_dcache_page_asm and flush_icache_page_asm · febe4296
      John David Anglin authored
      We have four routines in pacache.S that use temporary alias pages:
      copy_user_page_asm(), clear_user_page_asm(), flush_dcache_page_asm() and
      flush_icache_page_asm().  copy_user_page_asm() and clear_user_page_asm()
      don't purge the TLB entry used for the operation.
      flush_dcache_page_asm() and flush_icache_page_asm do purge the entry.
      
      Presumably, this was thought to optimize TLB use.  However, the
      operation is quite heavy weight on PA 1.X processors as we need to take
      the TLB lock and a TLB broadcast is sent to all processors.
      
      This patch removes the purges from flush_dcache_page_asm() and
      flush_icache_page_asm.
      Signed-off-by: default avatarJohn David Anglin  <dave.anglin@bell.net>
      Cc: <stable@vger.kernel.org> # v3.16+
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      febe4296
    • John David Anglin's avatar
      parisc: Purge TLB before setting PTE · c78e710c
      John David Anglin authored
      The attached change interchanges the order of purging the TLB and
      setting the corresponding page table entry.  TLB purges are strongly
      ordered.  It occurred to me one night that setting the PTE first might
      have subtle ordering issues on SMP machines and cause random memory
      corruption.
      
      A TLB lock guards the insertion of user TLB entries.  So after the TLB
      is purged, a new entry can't be inserted until the lock is released.
      This ensures that the new PTE value is used when the lock is released.
      
      Since making this change, no random segmentation faults have been
      observed on the Debian hppa buildd servers.
      Signed-off-by: default avatarJohn David Anglin  <dave.anglin@bell.net>
      Cc: <stable@vger.kernel.org> # v3.16+
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      c78e710c