1. 30 10月, 2005 1 次提交
    • N
      [PATCH] core remove PageReserved · b5810039
      Nick Piggin 提交于
      Remove PageReserved() calls from core code by tightening VM_RESERVED
      handling in mm/ to cover PageReserved functionality.
      
      PageReserved special casing is removed from get_page and put_page.
      
      All setting and clearing of PageReserved is retained, and it is now flagged
      in the page_alloc checks to help ensure we don't introduce any refcount
      based freeing of Reserved pages.
      
      MAP_PRIVATE, PROT_WRITE of VM_RESERVED regions is tentatively being
      deprecated.  We never completely handled it correctly anyway, and is be
      reintroduced in future if required (Hugh has a proof of concept).
      
      Once PageReserved() calls are removed from kernel/power/swsusp.c, and all
      arch/ and driver code, the Set and Clear calls, and the PG_reserved bit can
      be trivially removed.
      
      Last real user of PageReserved is swsusp, which uses PageReserved to
      determine whether a struct page points to valid memory or not.  This still
      needs to be addressed (a generic page_is_ram() should work).
      
      A last caveat: the ZERO_PAGE is now refcounted and managed with rmap (and
      thus mapcounted and count towards shared rss).  These writes to the struct
      page could cause excessive cacheline bouncing on big systems.  There are a
      number of ways this could be addressed if it is an issue.
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      
      Refcount bug fix for filemap_xip.c
      Signed-off-by: NCarsten Otte <cotte@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b5810039
  2. 12 10月, 2005 1 次提交
  3. 05 9月, 2005 1 次提交
    • H
      [PATCH] mm: fix madvise vma merging · 836d5ffd
      Hugh Dickins 提交于
      Better late than never, I've at last reviewed the madvise vma merging
      going into 2.6.13.  Remove a pointless check and fix two little bugs -
      a simple test (with /proc/<pid>/maps hacked to show ReadHints) showed
      both mismerges in practice: though being madvise, neither was disastrous.
      
      1. Correct placement of the success label in madvise_behavior: as in
         mprotect_fixup and mlock_fixup, it is necessary to update vm_flags
         when vma_merge succeeds (to handle the exceptional Case 8 noted in
         the comments above vma_merge itself).
      
      2. Correct initial value of prev when starting part way into a vma: as
         in sys_mprotect and do_mlock, it needs to be set to vma in this case
         (vma_merge handles only that minimum of cases shown in its comments).
      
      3. If find_vma_prev sets prev, then the vma it returns is prev->vm_next,
         so it's pointless to make that same assignment again in sys_madvise.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      836d5ffd
  4. 28 7月, 2005 1 次提交
  5. 24 6月, 2005 2 次提交
  6. 22 6月, 2005 2 次提交
  7. 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