1. 29 7月, 2009 1 次提交
  2. 29 6月, 2009 1 次提交
  3. 04 4月, 2009 1 次提交
  4. 02 4月, 2009 1 次提交
  5. 01 4月, 2009 2 次提交
  6. 30 3月, 2009 1 次提交
  7. 13 3月, 2009 1 次提交
  8. 11 3月, 2009 2 次提交
  9. 05 3月, 2009 1 次提交
    • P
      x86: set_highmem_pages_init() cleanup, #2 · 6298e719
      Pekka Enberg 提交于
      Impact: cleanup
      
      The zones are set up at this stage so there's a highmem zone
      available even for the UMA case.
      
      The only difference there is that for machines that have
      CONFIG_HIGHMEM enabled but don't have any highmem available,
      ->zone_start_pfn is zero whereas highstart_pfn is non-zero).
      
      The field is left zeroed because of the !size test in
      free_area_init_core() but shouldn't be a problem because
      add_highpages_with_active_regions() handles empty ranges just
      fine.
      Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
      Cc: Mel Gorman <mel@csn.ul.ie>
      LKML-Reference: <1236154567.29024.23.camel@penberg-laptop>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      6298e719
  10. 03 3月, 2009 2 次提交
  11. 18 10月, 2008 1 次提交
  12. 01 5月, 2008 1 次提交
  13. 29 3月, 2008 1 次提交
  14. 30 1月, 2008 1 次提交
  15. 11 10月, 2007 2 次提交
  16. 12 9月, 2007 1 次提交
    • A
      revert "highmem: catch illegal nesting" · 4150d3f5
      Andrew Morton 提交于
      Revert
      
      	commit 656dad31
      	Author: Ingo Molnar <mingo@elte.hu>
      	Date:   Sat Feb 10 01:46:36 2007 -0800
      
      	[PATCH] highmem: catch illegal nesting
      
      	Catch illegally nested kmap_atomic()s even if the page that is mapped by
      	the 'inner' instance is from lowmem.
      
      	This avoids spuriously zapped kmap-atomic ptes and turns hard to find
      	crashes into clear asserts at the bug site.
      
      Problem is, a get_zeroed_page(GFP_KERNEL) from interrupt context will trigger
      this check if non-irq code on this CPU holds a KM_USER0 mapping.  But that
      get_zeroed_page() will never be altering the kmap slot anyway due to the
      GFP_KERNEL.
      
      Cc: Christoph Lameter <clameter@sgi.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4150d3f5
  17. 03 5月, 2007 2 次提交
  18. 09 4月, 2007 1 次提交
  19. 12 2月, 2007 1 次提交
  20. 08 12月, 2006 2 次提交
  21. 01 10月, 2006 1 次提交
    • Z
      [PATCH] paravirt: kpte flush · 23002d88
      Zachary Amsden 提交于
      Create a new PTE function which combines clearing a kernel PTE with the
      subsequent flush.  This allows the two to be easily combined into a single
      hypercall or paravirt-op.  More subtly, reverse the order of the flush for
      kmap_atomic.  Instead of flushing on establishing a mapping, flush on clearing
      a mapping.  This eliminates the possibility of leaving stale kmap entries
      which may still have valid TLB mappings.  This is required for direct mode
      hypervisors, which need to reprotect all mappings of a given page when
      changing the page type from a normal page to a protected page (such as a page
      table or descriptor table page).  But it also provides some nicer semantics
      for real hardware, by providing extra debug-proofing against using stale
      mappings, as well as ensuring that no stale mappings exist when changing the
      cacheability attributes of a page, which could lead to cache conflicts when
      two different types of mappings exist for the same page.
      Signed-off-by: NZachary Amsden <zach@vmware.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Jeremy Fitzhardinge <jeremy@xensource.com>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      23002d88
  22. 26 9月, 2006 1 次提交
  23. 26 6月, 2005 1 次提交
  24. 24 6月, 2005 1 次提交
  25. 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