1. 09 1月, 2014 1 次提交
    • J
      parisc: Ensure full cache coherency for kmap/kunmap · f8dae006
      John David Anglin 提交于
      Helge Deller noted a few weeks ago problems with the AIO support on
      parisc. This change is the result of numerous iterations on how best to
      deal with this problem.
      
      The solution adopted here is to provide full cache coherency in a
      uniform manner on all parisc systems. This involves calling
      flush_dcache_page() on kmap operations and flush_kernel_dcache_page() on
      kunmap operations. As a result, the copy_user_page() and
      clear_user_page() functions can be removed and the overall code is
      simpler.
      
      The change ensures that both userspace and kernel aliases to a mapped
      page are invalidated and flushed. This is necessary for the correct
      operation of PA8800 and PA8900 based systems which do not support
      inequivalent aliases.
      
      With this change, I have observed no cache related issues on c8000 and
      rp3440. It is now possible for example to do kernel builds with "-j64"
      on four way systems.
      
      On systems using XFS file systems, the patch recently posted by Mikulas
      Patocka to "fix crash using XFS on loopback" is needed to avoid a hang
      caused by an uninitialized lock passed to flush_dcache_page() in the
      page struct.
      Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
      Cc: stable@vger.kernel.org # v3.9+
      Signed-off-by: NHelge Deller <deller@gmx.de>
      f8dae006
  2. 20 10月, 2013 1 次提交
  3. 13 10月, 2013 1 次提交
  4. 01 8月, 2013 1 次提交
    • J
      parisc: Fix cache routines to ignore vma's with an invalid pfn · 50861f5a
      John David Anglin 提交于
      The parisc architecture does not have a pte special bit. As a result,
      special mappings are handled with the VM_PFNMAP and VM_MIXEDMAP flags.
      VM_MIXEDMAP mappings may or may not have a "struct page" backing. When
      pfn_valid() is false, there is no "struct page" backing. Otherwise, they
      are treated as normal pages.
      
      The FireGL driver uses the VM_MIXEDMAP without a backing "struct page".
      This treatment caused a panic due to a TLB data miss in
      update_mmu_cache. This appeared to be in the code generated for
      page_address(). We were in fact using a very circular bit of code to
      determine the physical address of the PFN in various cache routines.
      This wasn't valid when there was no "struct page" backing.  The needed
      address can in fact be determined simply from the PFN itself without
      using the "struct page".
      
      The attached patch updates update_mmu_cache(), flush_cache_mm(),
      flush_cache_range() and flush_cache_page() to check pfn_valid() and to
      directly compute the PFN physical and virtual addresses.
      Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
      Cc: <stable@vger.kernel.org> # 3.10
      Signed-off-by: NHelge Deller <deller@gmx.de>
      50861f5a
  5. 10 7月, 2013 1 次提交
    • J
      parisc: Ensure volatile space register %sr1 is not clobbered · e8d8fc21
      John David Anglin 提交于
      I still see the occasional random segv on rp3440.  Looking at one of
      these (a code 15), it appeared the problem must be with the cache
      handling of anonymous pages.  Reviewing this, I noticed that the space
      register %sr1 might be being clobbered when we flush an anonymous page.
      
      Register %sr1 is used for TLB purges in a couple of places.  These
      purges are needed on PA8800 and PA8900 processors to ensure cache
      consistency of flushed cache lines.
      
      The solution here is simply to move the %sr1 load into the TLB lock
      region needed to ensure that one purge executes at a time on SMP
      systems.  This was already the case for one use.  After a few days of
      operation, I haven't had a random segv on my rp3440.
      Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
      Cc: <stable@vger.kernel.org> # 3.10
      Signed-off-by: NHelge Deller <deller@gmx.de>
      e8d8fc21
  6. 08 5月, 2013 1 次提交
  7. 07 5月, 2013 1 次提交
  8. 26 4月, 2013 1 次提交
    • J
      parisc: use spin_lock_irqsave/spin_unlock_irqrestore for PTE updates · bda079d3
      John David Anglin 提交于
      User applications running on SMP kernels have long suffered from instability
      and random segmentation faults.  This patch improves the situation although
      there is more work to be done.
      
      One of the problems is the various routines in pgtable.h that update page table
      entries use different locking mechanisms, or no lock at all (set_pte_at).  This
      change modifies the routines to all use the same lock pa_dbit_lock.  This lock
      is used for dirty bit updates in the interruption code. The patch also purges
      the TLB entries associated with the PTE to ensure that inconsistent values are
      not used after the page table entry is updated.  The UP and SMP code are now
      identical.
      
      The change also includes a minor update to the purge_tlb_entries function in
      cache.c to improve its efficiency.
      Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
      Cc: Helge Deller <deller@gmx.de>
      Signed-off-by: NHelge Deller <deller@gmx.de>
      bda079d3
  9. 21 2月, 2013 4 次提交
    • J
      parisc: disable preemption while flushing D- or I-caches through TMPALIAS region · 027f27c4
      John David Anglin 提交于
      It is necessary to disable preemption during cache flushes done through the
      TMPALIAS region to ensure that the TLB setup is not clobbered by another flush.
      Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
      Signed-off-by: NHelge Deller <deller@gmx.de>
      027f27c4
    • J
      parisc: fixes and cleanups in page cache flushing (4/4) · cca8e902
      John David Anglin 提交于
      CONFIG_PARISC_TMPALIAS enables clear_user_highpage and copy_user_highpage.
      These are essentially alternative implementations of clear_user_page and
      copy_user_page.  They don't have anything to do with x86 high pages, but they
      build on the infrastructure to save a few instructions.  Read the comment in
      clear_user_highpage as it is very important to the implementation.  For this
      reason, there isn't any gain in using the TMPALIAS/highpage approach.
      Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
      Signed-off-by: NHelge Deller <deller@gmx.de>
      cca8e902
    • J
      parisc: fixes and cleanups in page cache flushing (3/4) · 6d2439d9
      John David Anglin 提交于
      flush_cache_mm, for the non current case also uses flush_dcache_page_asm
      and flush_icache_page_asm which are TMPALIAS flushes.
      
      For the non current case, the algorithm used by get_ptep is derived from the
      vmalloc_to_page implementation in vmalloc.c.  It is essentially a generic page
      table lookup.  The other alternative was to duplicate the lookup in entry.S.
      The break point for switching to a full cache flush is somewhat arbitrary.  The
      same approach is used in flush_cache_range for non current case.  In a GCC
      build and check, many small programs are executed and this change provided a
      significant performance enhancement, e.g. GCC build time was cut almost in half
      on a rp3440 at j4.  Previously, we always flushed the entire cache.
      Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
      Signed-off-by: NHelge Deller <deller@gmx.de>
      6d2439d9
    • J
      parisc: fixes and cleanups in page cache flushing (1/4) · 76334539
      John David Anglin 提交于
      This is the first patch in a series of 4, with which the page cache flushing of
      parisc will gets fixed and enhanced. This even fixes the nasty "minifail" bug
      (http://wiki.parisc-linux.org/TestCases?highlight=%28minifail%29) which
      prevented parisc to stay an official debian port.  Basically the flush in
      copy_user_page together with the TLB patch from commit
      7139bc15 is what fixes the minifail bug.
      
      This patch still uses the TMPALIAS approach.  The new copy_user_page
      implementation calls flush_dcache_page_asm to flush the user dcache page
      (crucial for minifail fix) via a kernel TMPALIAS mapping.  After that, it just
      copies the page using the kernel mapping.  It does a final flush if needed.
      Generally it is hard to avoid doing some cache flushes using the kernel mapping
      (e.g., copy_to_user_page and copy_from_user_page).
      
      This patch depends on a subsequent change to pacache.S implementing
      clear_page_asm and copy_page_asm.  These are optimized routines to clear and
      copy a page.  The calls in clear_user_page and copy_user_page could be replaced
      by calls to memset and memcpy, respectively.  I tested prefetch optimizations
      in clear_page_asm and copy_page_asm but didn't see any significant performance
      improvement on rp3440.  I'm not sure if these are routines are significantly
      faster than memset and/or memcpy, but they are there for further performance
      evaluation.
      Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
      Signed-off-by: NHelge Deller <deller@gmx.de>
      76334539
  10. 19 1月, 2013 1 次提交
  11. 09 10月, 2012 1 次提交
    • M
      mm: replace vma prio_tree with an interval tree · 6b2dbba8
      Michel Lespinasse 提交于
      Implement an interval tree as a replacement for the VMA prio_tree.  The
      algorithms are similar to lib/interval_tree.c; however that code can't be
      directly reused as the interval endpoints are not explicitly stored in the
      VMA.  So instead, the common algorithm is moved into a template and the
      details (node type, how to get interval endpoints from the node, etc) are
      filled in using the C preprocessor.
      
      Once the interval tree functions are available, using them as a
      replacement to the VMA prio tree is a relatively simple, mechanical job.
      Signed-off-by: NMichel Lespinasse <walken@google.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Hillf Danton <dhillf@gmail.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6b2dbba8
  12. 29 3月, 2012 1 次提交
  13. 16 4月, 2011 1 次提交
    • J
      [PARISC] prevent speculative re-read on cache flush · b7d45818
      James Bottomley 提交于
      According to Appendix F, the TLB is the primary arbiter of speculation.
      Thus, if a page has a TLB entry, it may be speculatively read into the
      cache.  On linux, this can cause us incoherencies because if we're about
      to do a disk read, we call get_user_pages() to do the flush/invalidate
      in user space, but we still potentially have the user TLB entries, and
      the cache could speculate the lines back into userspace (thus causing
      stale data to be used).  This is fixed by purging the TLB entries before
      we flush through the tmpalias space.  Now, the only way the line could
      be re-speculated is if the user actually tries to touch it (which is not
      allowed).
      Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      b7d45818
  14. 15 1月, 2011 1 次提交
    • J
      parisc: flush pages through tmpalias space · f311847c
      James Bottomley 提交于
      The kernel has an 8M tmpailas space (originally designed for copying
      and clearing pages but now only used for clearing).  The idea is
      to place zeros into the cache above a physical page rather than into
      the physical page and flush the cache, because often the zeros end up
      being replaced quickly anyway.
      
      We can also use the tmpalias space for flushing a page.  The difference
      here is that we have to do tmpalias processing in the non access data and
      instruction traps.  The principle is the same: as long as we know the physical
      address and have a virtual address congruent to the real one, the flush will
      be effective.
      
      In order to use the tmpalias space, the icache miss path has to be enhanced to
      check for the alias region to make the fic instruction effective.
      Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      f311847c
  15. 07 3月, 2010 1 次提交
  16. 21 2月, 2010 1 次提交
    • R
      MM: Pass a PTE pointer to update_mmu_cache() rather than the PTE itself · 4b3073e1
      Russell King 提交于
      On VIVT ARM, when we have multiple shared mappings of the same file
      in the same MM, we need to ensure that we have coherency across all
      copies.  We do this via make_coherent() by making the pages
      uncacheable.
      
      This used to work fine, until we allowed highmem with highpte - we
      now have a page table which is mapped as required, and is not available
      for modification via update_mmu_cache().
      
      Ralf Beache suggested getting rid of the PTE value passed to
      update_mmu_cache():
      
        On MIPS update_mmu_cache() calls __update_tlb() which walks pagetables
        to construct a pointer to the pte again.  Passing a pte_t * is much
        more elegant.  Maybe we might even replace the pte argument with the
        pte_t?
      
      Ben Herrenschmidt would also like the pte pointer for PowerPC:
      
        Passing the ptep in there is exactly what I want.  I want that
        -instead- of the PTE value, because I have issue on some ppc cases,
        for I$/D$ coherency, where set_pte_at() may decide to mask out the
        _PAGE_EXEC.
      
      So, pass in the mapped page table pointer into update_mmu_cache(), and
      remove the PTE value, updating all implementations and call sites to
      suit.
      
      Includes a fix from Stephen Rothwell:
      
        sparc: fix fallout from update_mmu_cache API change
      Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      4b3073e1
  17. 03 7月, 2009 2 次提交
  18. 13 3月, 2009 1 次提交
  19. 26 6月, 2008 1 次提交
  20. 03 2月, 2008 1 次提交
  21. 22 5月, 2007 1 次提交
    • A
      Detach sched.h from mm.h · e8edc6e0
      Alexey Dobriyan 提交于
      First thing mm.h does is including sched.h solely for can_do_mlock() inline
      function which has "current" dereference inside. By dealing with can_do_mlock()
      mm.h can be detached from sched.h which is good. See below, why.
      
      This patch
      a) removes unconditional inclusion of sched.h from mm.h
      b) makes can_do_mlock() normal function in mm/mlock.c
      c) exports can_do_mlock() to not break compilation
      d) adds sched.h inclusions back to files that were getting it indirectly.
      e) adds less bloated headers to some files (asm/signal.h, jiffies.h) that were
         getting them indirectly
      
      Net result is:
      a) mm.h users would get less code to open, read, preprocess, parse, ... if
         they don't need sched.h
      b) sched.h stops being dependency for significant number of files:
         on x86_64 allmodconfig touching sched.h results in recompile of 4083 files,
         after patch it's only 3744 (-8.3%).
      
      Cross-compile tested on
      
      	all arm defconfigs, all mips defconfigs, all powerpc defconfigs,
      	alpha alpha-up
      	arm
      	i386 i386-up i386-defconfig i386-allnoconfig
      	ia64 ia64-up
      	m68k
      	mips
      	parisc parisc-up
      	powerpc powerpc-up
      	s390 s390-up
      	sparc sparc-up
      	sparc64 sparc64-up
      	um-x86_64
      	x86_64 x86_64-up x86_64-defconfig x86_64-allnoconfig
      
      as well as my two usual configs.
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e8edc6e0
  22. 17 2月, 2007 2 次提交
  23. 04 10月, 2006 3 次提交
  24. 28 6月, 2006 2 次提交
  25. 22 4月, 2006 1 次提交
  26. 31 3月, 2006 1 次提交
  27. 11 1月, 2006 2 次提交
  28. 30 10月, 2005 1 次提交
  29. 22 10月, 2005 1 次提交
  30. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4