1. 24 3月, 2006 1 次提交
    • A
      [PATCH] x86_64: {set,clear,test}_bit() related cleanup and pci_mmcfg_init() fix · 3d1712c9
      Akinobu Mita 提交于
      While working on these patch set, I found several possible cleanup on x86-64
      and ia64.
      
      akpm: I stole this from Andi's queue.
      
      Not only does it clean up bitops.  It also unrelatedly changes the prototype
      of pci_mmcfg_init() and removes its arch_initcall().  It seems that the wrong
      two patches got joined together, but this is the one which has been tested.
      
      This patch fixes the current x86_64 build error (the pci_mmcfg_init()
      declaration in arch/i386/pci/pci.h disagrees with the definition in
      arch/x86_64/pci/mmconfig.c)
      
      This also means that x86_64's pci_mmcfg_init() gets called in the same (new)
      manner as x86's: from arch/i386/pci/init.c:pci_access_init(), rather than via
      initcall.
      
      The bitops cleanups came along for free.
      
      All this worked OK in -mm testing (since 2.6.16-rc4-mm1) because x86_64 was
      tested with both patches applied.
      Signed-off-by: NAkinobu Mita <mita@miraclelinux.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Cc: Con Kolivas <kernel@kolivas.org>
      Cc: Jean Delvare <khali@linux-fr.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3d1712c9
  2. 22 3月, 2006 1 次提交
    • Z
      [PATCH] Enable mprotect on huge pages · 8f860591
      Zhang, Yanmin 提交于
      2.6.16-rc3 uses hugetlb on-demand paging, but it doesn_t support hugetlb
      mprotect.
      
      From: David Gibson <david@gibson.dropbear.id.au>
      
        Remove a test from the mprotect() path which checks that the mprotect()ed
        range on a hugepage VMA is hugepage aligned (yes, really, the sense of
        is_aligned_hugepage_range() is the opposite of what you'd guess :-/).
      
        In fact, we don't need this test.  If the given addresses match the
        beginning/end of a hugepage VMA they must already be suitably aligned.  If
        they don't, then mprotect_fixup() will attempt to split the VMA.  The very
        first test in split_vma() will check for a badly aligned address on a
        hugepage VMA and return -EINVAL if necessary.
      
      From: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
      
        On i386 and x86-64, pte flag _PAGE_PSE collides with _PAGE_PROTNONE.  The
        identify of hugetlb pte is lost when changing page protection via mprotect.
        A page fault occurs later will trigger a bug check in huge_pte_alloc().
      
        The fix is to always make new pte a hugetlb pte and also to clean up
        legacy code where _PAGE_PRESENT is forced on in the pre-faulting day.
      Signed-off-by: NZhang Yanmin <yanmin.zhang@intel.com>
      Cc: David Gibson <david@gibson.dropbear.id.au>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: William Lee Irwin III <wli@holomorphy.com>
      Signed-off-by: NKen Chen <kenneth.w.chen@intel.com>
      Signed-off-by: NNishanth Aravamudan <nacc@us.ibm.com>
      Cc: Andi Kleen <ak@muc.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8f860591
  3. 27 2月, 2006 1 次提交
  4. 12 1月, 2006 1 次提交
  5. 07 1月, 2006 1 次提交
  6. 15 11月, 2005 2 次提交
  7. 07 11月, 2005 1 次提交
  8. 31 10月, 2005 1 次提交
    • T
      [PATCH] vm: remove unused/broken page_pte[_prot] macros · 1426d7a8
      Tejun Heo 提交于
      This patch removes page_pte_prot and page_pte macros from all
      architectures.  Some architectures define both, some only page_pte (broken)
      and others none.  These macros are not used anywhere.
      
      page_pte_prot(page, prot) is identical to mk_pte(page, prot) and
      page_pte(page) is identical to page_pte_prot(page, __pgprot(0)).
      
      * The following architectures define both page_pte_prot and page_pte
      
        arm, arm26, ia64, sh64, sparc, sparc64
      
      * The following architectures define only page_pte (broken)
      
        frv, i386, m32r, mips, sh, x86-64
      
      * All other architectures define neither
      Signed-off-by: NTejun Heo <htejun@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1426d7a8
  9. 30 9月, 2005 1 次提交
  10. 13 9月, 2005 2 次提交
  11. 05 9月, 2005 3 次提交
  12. 30 7月, 2005 1 次提交
  13. 22 6月, 2005 1 次提交
    • D
      [PATCH] Hugepage consolidation · 63551ae0
      David Gibson 提交于
      A lot of the code in arch/*/mm/hugetlbpage.c is quite similar.  This patch
      attempts to consolidate a lot of the code across the arch's, putting the
      combined version in mm/hugetlb.c.  There are a couple of uglyish hacks in
      order to covert all the hugepage archs, but the result is a very large
      reduction in the total amount of code.  It also means things like hugepage
      lazy allocation could be implemented in one place, instead of six.
      
      Tested, at least a little, on ppc64, i386 and x86_64.
      
      Notes:
      	- this patch changes the meaning of set_huge_pte() to be more
      	  analagous to set_pte()
      	- does SH4 need s special huge_ptep_get_and_clear()??
      Acked-by: NWilliam Lee Irwin <wli@holomorphy.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      63551ae0
  14. 20 4月, 2005 1 次提交
  15. 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