1. 26 9月, 2006 2 次提交
    • A
      [PATCH] Convert x86-64 to early param · 2c8c0e6b
      Andi Kleen 提交于
      Instead of hackish manual parsing
      
      Requires earlier i386 patchkit, but also fixes i386 early_printk again.
      
      I removed some obsolete really early parameters which didn't do anything useful.
      Also made a few parameters that needed it early (mostly oops printing setup)
      
      Also removed one panic check that wasn't visible without
      early console anyways (the early console is now initialized after that
      panic)
      
      This cleans up a lot of code.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      2c8c0e6b
    • A
      [PATCH] Clean up and minor fixes to TLB flush · b1c78c0f
      Andi Kleen 提交于
      - Convert CR* accesses to dedicated inline functions and rewrite
      the rest as C inlines
      - Don't do a double flush for global flushes (pointed out by Zach Amsden)
      This was a bug workaround for old CPUs that don't do 64bit and is obsolete.
      - Add a proper memory clobber to invlpg
      - Remove an unused extern
      Signed-off-by: NAndi Kleen <ak@suse.de>
      b1c78c0f
  2. 27 6月, 2006 1 次提交
  3. 26 3月, 2006 1 次提交
    • J
      [PATCH] x86_64: actively synchronize vmalloc area when registering certain callbacks · 8c914cb7
      Jan Beulich 提交于
      While the modular aspect of the respective i386 patch doesn't apply to
      x86-64 (as the top level page directory entry is shared between modules
      and the base kernel), handlers registered with register_die_notifier()
      are still under similar constraints for touching ioremap()ed or
      vmalloc()ed memory. The likelihood of this problem becoming visible is
      of course significantly lower, as the assigned virtual addresses would
      have to cross a 2**39 byte boundary. This is because the callback gets
      invoked
      (a) in the page fault path before the top level page table propagation
      gets carried out (hence a fault to propagate the top level page table
      entry/entries mapping to module's code/data would nest infinitly) and
      (b) in the NMI path, where nested faults must absolutely not happen,
      since otherwise the IRET from the nested fault re-enables NMIs,
      potentially resulting in nested NMI occurences.
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8c914cb7
  4. 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
  5. 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
  6. 27 2月, 2006 1 次提交
  7. 12 1月, 2006 1 次提交
  8. 07 1月, 2006 1 次提交
  9. 15 11月, 2005 2 次提交
  10. 07 11月, 2005 1 次提交
  11. 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
  12. 30 9月, 2005 1 次提交
  13. 13 9月, 2005 2 次提交
  14. 05 9月, 2005 3 次提交
  15. 30 7月, 2005 1 次提交
  16. 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
  17. 20 4月, 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