1. 15 4月, 2015 2 次提交
    • K
      mm: expose arch_mmap_rnd when available · 2b68f6ca
      Kees Cook 提交于
      When an architecture fully supports randomizing the ELF load location,
      a per-arch mmap_rnd() function is used to find a randomized mmap base.
      In preparation for randomizing the location of ET_DYN binaries
      separately from mmap, this renames and exports these functions as
      arch_mmap_rnd(). Additionally introduces CONFIG_ARCH_HAS_ELF_RANDOMIZE
      for describing this feature on architectures that support it
      (which is a superset of ARCH_BINFMT_ELF_RANDOMIZE_PIE, since s390
      already supports a separated ET_DYN ASLR from mmap ASLR without the
      ARCH_BINFMT_ELF_RANDOMIZE_PIE logic).
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Cc: Hector Marco-Gisbert <hecmargi@upv.es>
      Cc: Russell King <linux@arm.linux.org.uk>
      Reviewed-by: NIngo Molnar <mingo@kernel.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: "David A. Long" <dave.long@linaro.org>
      Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
      Cc: Arun Chandran <achandran@mvista.com>
      Cc: Yann Droneaud <ydroneaud@opteya.com>
      Cc: Min-Hua Chen <orca.chen@gmail.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Alex Smith <alex@alex-smith.me.uk>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: Vineeth Vijayan <vvijayan@mvista.com>
      Cc: Jeff Bailey <jeffbailey@google.com>
      Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Behan Webster <behanw@converseincode.com>
      Cc: Ismael Ripoll <iripoll@upv.es>
      Cc: Jan-Simon Mller <dl9pf@gmx.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2b68f6ca
    • K
      mips: extract logic for mmap_rnd() · 1f0569df
      Kees Cook 提交于
      In preparation for splitting out ET_DYN ASLR, extract the mmap ASLR
      selection into a separate function.
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Reviewed-by: NIngo Molnar <mingo@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1f0569df
  2. 10 4月, 2015 1 次提交
  3. 02 4月, 2015 1 次提交
    • M
      MIPS: c-r4k.c: Fix the 74K D-cache alias erratum workaround · e2e7f29a
      Maciej W. Rozycki 提交于
      Fix the 74K D-cache alias erratum workaround so that it actually works.
      Our current code sets MIPS_CACHE_VTAG for the D-cache, but that flag
      only has any effect for the I-cache.  Additionally MIPS_CACHE_PINDEX is
      set for the D-cache if CP0.Config7.AR is also set for an affected
      processor, leading to confusing information in the bootstrap log (the
      flag isn't used beyond that).
      
      So delete the setting of MIPS_CACHE_VTAG and rely on MIPS_CACHE_ALIASES,
      set in a common place, removing I-cache coherency issues seen in GDB
      testing with software breakpoints, gdbserver and ptrace(2), on affected
      systems.
      
      While at it add a little piece of explanation of what CP0.Config6.SYND
      is so that people do not have to chase documentation.
      Signed-off-by: NMaciej W. Rozycki <macro@codesourcery.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/8507/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      e2e7f29a
  4. 01 4月, 2015 2 次提交
  5. 25 3月, 2015 2 次提交
    • L
      MIPS: Fix race condition in lazy cache flushing. · 4d46a67a
      Lars Persson 提交于
      The lazy cache flushing implemented in the MIPS kernel suffers from a
      race condition that is exposed by do_set_pte() in mm/memory.c.
      
      A pre-condition is a file-system that writes to the page from the CPU
      in its readpage method and then calls flush_dcache_page(). One example
      is ubifs. Another pre-condition is that the dcache flush is postponed
      in __flush_dcache_page().
      
      Upon a page fault for an executable mapping not existing in the
      page-cache, the following will happen:
      1. Write to the page
      2. flush_dcache_page
      3. flush_icache_page
      4. set_pte_at
      5. update_mmu_cache (commits the flush of a dcache-dirty page)
      
      Between steps 4 and 5 another thread can hit the same page and it will
      encounter a valid pte. Because the data still is in the L1 dcache the CPU
      will fetch stale data from L2 into the icache and execute garbage.
      
      This fix moves the commit of the cache flush to step 3 to close the
      race window. It also reduces the amount of flushes on non-executable
      mappings because we never enter __flush_dcache_page() for non-aliasing
      CPUs.
      
      Regressions can occur in drivers that mistakenly relies on the
      flush_dcache_page() in get_user_pages() for DMA operations.
      
      [ralf@linux-mips.org: Folded in patch 9346 to fix highmem issue.]
      Signed-off-by: NLars Persson <larper@axis.com>
      Cc: linux-mips@linux-mips.org
      Cc: paul.burton@imgtec.com
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/9346/
      Patchwork: https://patchwork.linux-mips.org/patch/9738/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      4d46a67a
    • L
      Revert "MIPS: Remove race window in page fault handling" · 5b9593f3
      Lars Persson 提交于
      Revert commit 2a4a8b1e ("MIPS: Remove race window in page fault
      handling") because it increased the number of flushed dcache pages and
      became a performance problem for some workloads.
      Signed-off-by: NLars Persson <larper@axis.com>
      Cc: linux-mips@linux-mips.org
      Cc: paul.burton@imgtec.com
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/9345/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      5b9593f3
  6. 20 3月, 2015 1 次提交
  7. 18 3月, 2015 1 次提交
    • S
      MIPS: Rearrange PTE bits into fixed positions. · be0c37c9
      Steven J. Hill 提交于
      This patch rearranges the PTE bits into fixed positions for R2
      and later cores. In the past, the TLB handling code did runtime
      checking of RI/XI and adjusted the shifts and rotates in order
      to fit the largest PFN value into the PTE. The checking now
      occurs when building the TLB handler, thus eliminating those
      checks. These new arrangements also define the largest possible
      PFN value that can fit in the PTE. HUGE page support is only
      available for 64-bit cores. Layouts of the PTE bits are now:
      
         64-bit, R1 or earlier:     CCC D V G [S H] M A W R P
         32-bit, R1 or earler:      CCC D V G M A W R P
         64-bit, R2 or later:       CCC D V G RI/R XI [S H] M A W P
         32-bit, R2 or later:       CCC D V G RI/R XI M A W P
      
      [ralf@linux-mips.org: Fix another build error *rant* *rant*]
      Signed-off-by: NSteven J. Hill <Steven.Hill@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/9353/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      be0c37c9
  8. 21 2月, 2015 1 次提交
  9. 20 2月, 2015 2 次提交
  10. 17 2月, 2015 4 次提交
  11. 16 2月, 2015 4 次提交
  12. 12 2月, 2015 2 次提交
    • A
      mm: gup: use get_user_pages_unlocked within get_user_pages_fast · a7b78075
      Andrea Arcangeli 提交于
      This allows the get_user_pages_fast slow path to release the mmap_sem
      before blocking.
      Signed-off-by: NAndrea Arcangeli <aarcange@redhat.com>
      Reviewed-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Andres Lagar-Cavilla <andreslc@google.com>
      Cc: Peter Feiner <pfeiner@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a7b78075
    • N
      mm/hugetlb: reduce arch dependent code around follow_huge_* · 61f77eda
      Naoya Horiguchi 提交于
      Currently we have many duplicates in definitions around
      follow_huge_addr(), follow_huge_pmd(), and follow_huge_pud(), so this
      patch tries to remove the m.  The basic idea is to put the default
      implementation for these functions in mm/hugetlb.c as weak symbols
      (regardless of CONFIG_ARCH_WANT_GENERAL_HUGETL B), and to implement
      arch-specific code only when the arch needs it.
      
      For follow_huge_addr(), only powerpc and ia64 have their own
      implementation, and in all other architectures this function just returns
      ERR_PTR(-EINVAL).  So this patch sets returning ERR_PTR(-EINVAL) as
      default.
      
      As for follow_huge_(pmd|pud)(), if (pmd|pud)_huge() is implemented to
      always return 0 in your architecture (like in ia64 or sparc,) it's never
      called (the callsite is optimized away) no matter how implemented it is.
      So in such architectures, we don't need arch-specific implementation.
      
      In some architecture (like mips, s390 and tile,) their current
      arch-specific follow_huge_(pmd|pud)() are effectively identical with the
      common code, so this patch lets these architecture use the common code.
      
      One exception is metag, where pmd_huge() could return non-zero but it
      expects follow_huge_pmd() to always return NULL.  This means that we need
      arch-specific implementation which returns NULL.  This behavior looks
      strange to me (because non-zero pmd_huge() implies that the architecture
      supports PMD-based hugepage, so follow_huge_pmd() can/should return some
      relevant value,) but that's beyond this cleanup patch, so let's keep it.
      
      Justification of non-trivial changes:
      - in s390, follow_huge_pmd() checks !MACHINE_HAS_HPAGE at first, and this
        patch removes the check. This is OK because we can assume MACHINE_HAS_HPAGE
        is true when follow_huge_pmd() can be called (note that pmd_huge() has
        the same check and always returns 0 for !MACHINE_HAS_HPAGE.)
      - in s390 and mips, we use HPAGE_MASK instead of PMD_MASK as done in common
        code. This patch forces these archs use PMD_MASK, but it's OK because
        they are identical in both archs.
        In s390, both of HPAGE_SHIFT and PMD_SHIFT are 20.
        In mips, HPAGE_SHIFT is defined as (PAGE_SHIFT + PAGE_SHIFT - 3) and
        PMD_SHIFT is define as (PAGE_SHIFT + PAGE_SHIFT + PTE_ORDER - 3), but
        PTE_ORDER is always 0, so these are identical.
      Signed-off-by: NNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Acked-by: NHugh Dickins <hughd@google.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Luiz Capitulino <lcapitulino@redhat.com>
      Cc: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
      Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
      Cc: Steve Capper <steve.capper@linaro.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      61f77eda
  13. 31 1月, 2015 1 次提交
    • D
      MIPS: Fix C0_Pagegrain[IEC] support. · 9ead8632
      David Daney 提交于
      The following commits:
      
        5890f70f (MIPS: Use dedicated exception handler if CPU supports RI/XI exceptions)
        6575b1d4 (MIPS: kernel: cpu-probe: Detect unique RI/XI exceptions)
      
      break the kernel for *all* existing MIPS CPUs that implement the
      CP0_PageGrain[IEC] bit.  They cause the TLB exception handlers to be
      generated without the legacy execute-inhibit handling, but never set
      the CP0_PageGrain[IEC] bit to activate the use of dedicated exception
      vectors for execute-inhibit exceptions.  The result is that upon
      detection of an execute-inhibit violation, we loop forever in the TLB
      exception handlers instead of sending SIGSEGV to the task.
      
      If we are generating TLB exception handlers expecting separate
      vectors, we must also enable the CP0_PageGrain[IEC] feature.
      
      The bug was introduced in kernel version 3.17.
      Signed-off-by: NDavid Daney <david.daney@cavium.com>
      Cc: <stable@vger.kernel.org>
      Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: http://patchwork.linux-mips.org/patch/8880/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      9ead8632
  14. 30 1月, 2015 1 次提交
    • L
      vm: add VM_FAULT_SIGSEGV handling support · 33692f27
      Linus Torvalds 提交于
      The core VM already knows about VM_FAULT_SIGBUS, but cannot return a
      "you should SIGSEGV" error, because the SIGSEGV case was generally
      handled by the caller - usually the architecture fault handler.
      
      That results in lots of duplication - all the architecture fault
      handlers end up doing very similar "look up vma, check permissions, do
      retries etc" - but it generally works.  However, there are cases where
      the VM actually wants to SIGSEGV, and applications _expect_ SIGSEGV.
      
      In particular, when accessing the stack guard page, libsigsegv expects a
      SIGSEGV.  And it usually got one, because the stack growth is handled by
      that duplicated architecture fault handler.
      
      However, when the generic VM layer started propagating the error return
      from the stack expansion in commit fee7e49d ("mm: propagate error
      from stack expansion even for guard page"), that now exposed the
      existing VM_FAULT_SIGBUS result to user space.  And user space really
      expected SIGSEGV, not SIGBUS.
      
      To fix that case, we need to add a VM_FAULT_SIGSEGV, and teach all those
      duplicate architecture fault handlers about it.  They all already have
      the code to handle SIGSEGV, so it's about just tying that new return
      value to the existing code, but it's all a bit annoying.
      
      This is the mindless minimal patch to do this.  A more extensive patch
      would be to try to gather up the mostly shared fault handling logic into
      one generic helper routine, and long-term we really should do that
      cleanup.
      
      Just from this patch, you can generally see that most architectures just
      copied (directly or indirectly) the old x86 way of doing things, but in
      the meantime that original x86 model has been improved to hold the VM
      semaphore for shorter times etc and to handle VM_FAULT_RETRY and other
      "newer" things, so it would be a good idea to bring all those
      improvements to the generic case and teach other architectures about
      them too.
      Reported-and-tested-by: NTakashi Iwai <tiwai@suse.de>
      Tested-by: NJan Engelhardt <jengelh@inai.de>
      Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> # "s390 still compiles and boots"
      Cc: linux-arch@vger.kernel.org
      Cc: stable@vger.kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      33692f27
  15. 18 12月, 2014 1 次提交
  16. 28 11月, 2014 1 次提交
  17. 25 11月, 2014 3 次提交
  18. 24 11月, 2014 4 次提交
  19. 20 11月, 2014 1 次提交
  20. 23 10月, 2014 1 次提交
    • D
      MIPS: tlbex: Properly fix HUGE TLB Refill exception handler · 9e0f162a
      David Daney 提交于
      In commit 8393c524 (MIPS: tlbex: Fix a missing statement for
      HUGETLB), the TLB Refill handler was fixed so that non-OCTEON targets
      would work properly with huge pages.  The change was incorrect in that
      it broke the OCTEON case.
      
      The problem is shown here:
      
          xxx0:	df7a0000 	ld	k0,0(k1)
          .
          .
          .
          xxxc0:	df610000 	ld	at,0(k1)
          xxxc4:	335a0ff0 	andi	k0,k0,0xff0
          xxxc8:	e825ffcd 	bbit1	at,0x5,0x0
          xxxcc:	003ad82d 	daddu	k1,at,k0
          .
          .
          .
      
      In the non-octeon case there is a destructive test for the huge PTE
      bit, and then at 0, $k0 is reloaded (that is what the 8393c524
      patch added).
      
      In the octeon case, we modify k1 in the branch delay slot, but we
      never need k0 again, so the new load is not needed, but since k1 is
      modified, if we do the load, we load from a garbage location and then
      get a nested TLB Refill, which is seen in userspace as either SIGBUS
      or SIGSEGV (depending on the garbage).
      
      The real fix is to only do this reloading if it is needed, and never
      where it is harmful.
      Signed-off-by: NDavid Daney <david.daney@cavium.com>
      Cc: Huacai Chen <chenhc@lemote.com>
      Cc: Fuxin Zhang <zhangfx@lemote.com>
      Cc: Zhangjin Wu <wuzhangjin@gmail.com>
      Cc: stable@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/8151/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      9e0f162a
  21. 22 9月, 2014 1 次提交
  22. 14 9月, 2014 1 次提交
  23. 26 8月, 2014 1 次提交
    • L
      MIPS: Remove race window in page fault handling · 4b34cdde
      Lars Persson 提交于
      Multicore MIPSes without I/D hardware coherency suffered from a race
      condition in the page fault handler. The page table entry was
      published before any pending lazy D-cache flush was committed, hence
      it allowed execution of stale page cache data by other VPEs in the
      system.
      
      To make the cache handling safe we need to perform flushing already in
      the set_pte_at function. MIPSes without coherent I-caches can get a
      small increase in flushes due to the unavailability of the execute
      flag in set_pte_at.
      
      [ralf@linux-mips.org: outlining set_pte_at() saves a good k in a test
      build, so I moved its definition from pgtable.h to cache.c.]
      Signed-off-by: NLars Persson <larper@axis.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/7511/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      4b34cdde
  24. 19 8月, 2014 1 次提交
    • L
      MIPS: Remove race window in page fault handling · 2a4a8b1e
      Lars Persson 提交于
      Multicore MIPSes without I/D hardware coherency suffered from a race
      condition in the page fault handler. The page table entry was
      published before any pending lazy D-cache flush was committed, hence
      it allowed execution of stale page cache data by other VPEs in the
      system.
      
      To make the cache handling safe we need to perform flushing already in
      the set_pte_at function. MIPSes without coherent I-caches can get a
      small increase in flushes due to the unavailability of the execute
      flag in set_pte_at.
      
      [ralf@linux-mips.org: outlining set_pte_at() saves a good k in a test
      build, so I moved its definition from pgtable.h to cache.c.]
      Signed-off-by: NLars Persson <larper@axis.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/7511/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      2a4a8b1e