1. 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
  2. 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
  3. 07 3月, 2010 1 次提交
  4. 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
  5. 03 7月, 2009 2 次提交
  6. 13 3月, 2009 1 次提交
  7. 26 6月, 2008 1 次提交
  8. 03 2月, 2008 1 次提交
  9. 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
  10. 17 2月, 2007 2 次提交
  11. 04 10月, 2006 3 次提交
  12. 28 6月, 2006 2 次提交
  13. 22 4月, 2006 1 次提交
  14. 31 3月, 2006 1 次提交
  15. 11 1月, 2006 2 次提交
  16. 30 10月, 2005 1 次提交
  17. 22 10月, 2005 1 次提交
  18. 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