1. 16 Oct, 2007 1 commit
    • Ralf Baechle's avatar
      [MIPS] Fix aliasing bug in copy_user_highpage, take 2. · 985c30ef
      Ralf Baechle authored
      Turns out b868868a
        wasn't quite right.
      When called for a page that isn't marked dirty it would artificially
      create an alias instead of doing the obvious thing and access the page
      via KSEG0.
      The same issue also exists in copy_to_user_page and copy_from_user_page
      which was causing the machine to die under rare circumstances for example
      when running ps if the BUG_ON() assertion added by the earlier fix was
      getting triggered.
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
  2. 11 Sep, 2007 1 commit
    • Ralf Baechle's avatar
      [MIPS] Fix aliasing bug in copy_user_highpage. · b868868a
      Ralf Baechle authored
      Copy_user_highpage was written assuming it was only being called for
      breaking COW pages in which case the source page isn't cached as in
      marked cachable under it kernel virtual address.  If it is called anyway
      the aliasing avoidance strategy implemented by kmap_coherent will fail.
      Avoid the use of kmap_coherent for pages marked dirty and to avoid
      another instance of this sort of bug, place a BUG_ON in kmap_coherent.
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
  3. 26 Aug, 2007 1 commit
  4. 24 Jul, 2007 1 commit
  5. 11 May, 2007 1 commit
  6. 27 Apr, 2007 2 commits
  7. 24 Mar, 2007 2 commits
  8. 19 Feb, 2007 1 commit
  9. 18 Feb, 2007 1 commit
  10. 06 Feb, 2007 3 commits
  11. 24 Jan, 2007 1 commit
  12. 13 Dec, 2006 1 commit
  13. 11 Dec, 2006 1 commit
  14. 29 Nov, 2006 3 commits
  15. 21 Oct, 2006 1 commit
  16. 03 Oct, 2006 1 commit
  17. 26 Sep, 2006 1 commit
  18. 13 Jul, 2006 1 commit
    • Atsushi Nemoto's avatar
      [MIPS] Do not count pages in holes with sparsemem · 565200a1
      Atsushi Nemoto authored
      With some memory model other than FLATMEM, the single node can
      contains some holes so there might be many invalid pages.  For
      example, with two 256M memory and one 256M hole, some variables
      (num_physpage, totalpages, nr_kernel_pages, nr_all_pages, etc.) will
      indicate that there are 768MB on this system.  This is not desired
      because, for example, alloc_large_system_hash() allocates too many
      Use free_area_init_node() with counted zholes_size[] instead of
      For num_physpages, use number of ram pages instead of max_low_pfn.
      Signed-off-by: default avatarAtsushi Nemoto <anemo@mba.ocn.ne.jp>
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
  19. 30 Jun, 2006 1 commit
  20. 05 Jun, 2006 1 commit
  21. 18 Apr, 2006 1 commit
  22. 27 Mar, 2006 1 commit
    • Dave Hansen's avatar
      [PATCH] unify PFN_* macros · 22a9835c
      Dave Hansen authored
      Just about every architecture defines some macros to do operations on pfns.
       They're all virtually identical.  This patch consolidates all of them.
      One minor glitch is that at least i386 uses them in a very skeletal header
      file.  To keep away from #include dependency hell, I stuck the new
      definitions in a new, isolated header.
      Of all of the implementations, sh64 is the only one that varied by a bit.
      It used some masks to ensure that any sign-extension got ripped away before
      the arithmetic is done.  This has been posted to that sh64 maintainers and
      the development list.
      Compiles on x86, x86_64, ia64 and ppc64.
      Signed-off-by: default avatarDave Hansen <haveblue@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  23. 22 Mar, 2006 2 commits
  24. 07 Feb, 2006 1 commit
  25. 12 Dec, 2005 1 commit
  26. 01 Dec, 2005 1 commit
  27. 29 Oct, 2005 3 commits
  28. 05 Sep, 2005 1 commit
  29. 25 Jun, 2005 1 commit
  30. 21 Jun, 2005 1 commit
  31. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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!