)]}'
{
  "log": [
    {
      "commit": "7bf07f3d4b4358aa6d99a26d7a0165f1e91c3fcc",
      "tree": "150e1f1172e3a7912b37bef7b06a657d47bc1657",
      "parents": [
        "32e51a8c976fc72c3e9bcece9767d9908816bf8e"
      ],
      "author": {
        "name": "Adam Litke",
        "email": "agl@us.ibm.com",
        "time": "Sat Sep 03 15:55:00 2005 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@evo.osdl.org",
        "time": "Mon Sep 05 00:05:46 2005 -0700"
      },
      "message": "[PATCH] hugetlb: move stale pte check into huge_pte_alloc()\n\nInitial Post (Wed, 17 Aug 2005)\n\nThis patch moves the\n\tif (! pte_none(*pte))\n\t\thugetlb_clean_stale_pgtable(pte);\nlogic into huge_pte_alloc() so all of its callers can be immune to the bug\ndescribed by Kenneth Chen at http://lkml.org/lkml/2004/6/16/246\n\n\u003e It turns out there is a bug in hugetlb_prefault(): with 3 level page table,\n\u003e huge_pte_alloc() might return a pmd that points to a PTE page. It happens\n\u003e if the virtual address for hugetlb mmap is recycled from previously used\n\u003e normal page mmap. free_pgtables() might not scrub the pmd entry on\n\u003e munmap and hugetlb_prefault skips on any pmd presence regardless what type\n\u003e it is.\n\nUnless I am missing something, it seems more correct to place the check inside\nhuge_pte_alloc() to prevent a the same bug wherever a huge pte is allocated.\nIt also allows checking for this condition when lazily faulting huge pages\nlater in the series.\n\nSigned-off-by: Adam Litke \u003cagl@us.ibm.com\u003e\nCc: \u003clinux-mm@kvack.org\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n"
    },
    {
      "commit": "c7546f8f03f5a4fa612605b6be930234d6026860",
      "tree": "e372cdb3856c9585587283c21b5b99a792a1a41d",
      "parents": [
        "e6cb99413da42af413c11a394538ddc8b9d201e1"
      ],
      "author": {
        "name": "David Gibson",
        "email": "david@gibson.dropbear.id.au",
        "time": "Fri Aug 05 11:59:35 2005 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@g5.osdl.org",
        "time": "Fri Aug 05 12:22:37 2005 -0700"
      },
      "message": "[PATCH] Fix hugepage crash on failing mmap()\n\nThis patch fixes a crash in the hugepage code.  unmap_hugepage_area() was\nassuming that (due to prefault) PTEs must exist for all the area in\nquestion.  However, this may not be the case, if mmap() encounters an error\nbefore the prefault and calls unmap_region() to clean up any partial\nmapping.\n\nDepending on the hugepage configuration, this crash can be triggered by an\nunpriveleged user.\n\nSigned-off-by: David Gibson \u003cdavid@gibson.dropbear.id.au\u003e\nCc: William Lee Irwin III \u003cwli@holomorphy.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n"
    },
    {
      "commit": "63551ae0feaaa23807ebea60de1901564bbef32e",
      "tree": "f6f97f60f83c3e9813bdfcc6039c499997b1ea10",
      "parents": [
        "1e7e5a9048b30c57ba1ddaa6cdf59b21b65cde99"
      ],
      "author": {
        "name": "David Gibson",
        "email": "david@gibson.dropbear.id.au",
        "time": "Tue Jun 21 17:14:44 2005 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@ppc970.osdl.org",
        "time": "Tue Jun 21 18:46:15 2005 -0700"
      },
      "message": "[PATCH] Hugepage consolidation\n\nA lot of the code in arch/*/mm/hugetlbpage.c is quite similar.  This patch\nattempts to consolidate a lot of the code across the arch\u0027s, putting the\ncombined version in mm/hugetlb.c.  There are a couple of uglyish hacks in\norder to covert all the hugepage archs, but the result is a very large\nreduction in the total amount of code.  It also means things like hugepage\nlazy allocation could be implemented in one place, instead of six.\n\nTested, at least a little, on ppc64, i386 and x86_64.\n\nNotes:\n\t- this patch changes the meaning of set_huge_pte() to be more\n\t  analagous to set_pte()\n\t- does SH4 need s special huge_ptep_get_and_clear()??\n\nAcked-by: William Lee Irwin \u003cwli@holomorphy.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n"
    },
    {
      "commit": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
      "tree": "0bba044c4ce775e45a88a51686b5d9f90697ea9d",
      "parents": [],
      "author": {
        "name": "Linus Torvalds",
        "email": "torvalds@ppc970.osdl.org",
        "time": "Sat Apr 16 15:20:36 2005 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@ppc970.osdl.org",
        "time": "Sat Apr 16 15:20:36 2005 -0700"
      },
      "message": "Linux-2.6.12-rc2\n\nInitial git repository build. I\u0027m not bothering with the full history,\neven though we have it. We can create a separate \"historical\" git\narchive of that later if we want to, and in the meantime it\u0027s about\n3.2GB when imported into git - space that would just make the early\ngit days unnecessarily complicated, when we don\u0027t have a lot of good\ninfrastructure for it.\n\nLet it rip!\n"
    }
  ]
}