)]}'
{
  "log": [
    {
      "commit": "9a61c349b28ec5aef7e929236571fd770fdef0bb",
      "tree": "c78c703dcca91302901d116031b311de7ad3fd78",
      "parents": [
        "4d7670e0f649f9e6e6ea6c8bb9f52441fa00f92b"
      ],
      "author": {
        "name": "Nick Piggin",
        "email": "nickpiggin@yahoo.com.au",
        "time": "Sat Sep 03 15:54:49 2005 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@evo.osdl.org",
        "time": "Mon Sep 05 00:05:44 2005 -0700"
      },
      "message": "[PATCH] mm: remap ZERO_PAGE mappings\n\nfilemap_xip\u0027s nopage routine maps the ZERO_PAGE into readonly mappings, if it\nhas no data page to map there: then if the hole in the file is later filled,\n__xip_unmap uses an rmap technique to replace the ZERO_PAGEs mapped for that\noffset by the newly allocated file page, so that established mappings will see\nthe newly written data.\n\nHowever, on MIPS (alone) there\u0027s not one but as many as eight ZERO_PAGEs,\nchosen for coloring by user virtual address; and if mremap has meanwhile been\nused to move a mapping containing a ZERO_PAGE, it will generally not match the\nZERO_PAGE(address) __xip_unmap is looking for.\n\nTo maintain XIP\u0027s established mappings correctly on MIPS, we need Nick\u0027s fix\nto mremap\u0027s move_one_page (originally presented as an optimization), to\nreplace the ZERO_PAGE appropriate to the old address by the ZERO_PAGE\nappropriate to the new address.\n\n(But when I first saw this, I was thinking the ZERO_PAGEs themselves would get\ncorrupted, very bad.  Now I think it\u0027s the other way round, that the\nestablished mappings will fail to see the newly written data: incorrect, but\nnot corrupting everything else.  Whether filemap_xip\u0027s technique is generally\nsafe, I\u0027d hesitate to say in a hurry: it\u0027s interesting, but we\u0027ve never tried\nto do that in tmpfs.)\n\nSigned-off-by: Hugh Dickins \u003chugh@veritas.com\u003e\nSigned-off-by: Nick Piggin \u003cnpiggin@suse.de\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n"
    },
    {
      "commit": "1c5ad84516ae7ea4ec868436a910a6bd8d20215a",
      "tree": "929e03789ee2191bbebe45fbd9b6c50865c5f9ca",
      "parents": [
        "e234f35c54a30d040313e40833dcf623d14629b4"
      ],
      "author": {
        "name": "Hugh Dickins",
        "email": "hugh@veritas.com",
        "time": "Thu Aug 04 13:07:09 2005 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@g5.osdl.org",
        "time": "Thu Aug 04 13:11:15 2005 -0700"
      },
      "message": "[PATCH] fix VmSize and VmData after mremap\n\nmremap\u0027s move_vma is applying __vm_stat_account to the old vma which may\nhave already been freed: move it to just before the do_munmap.\n\nmremapping to and fro with CONFIG_DEBUG_SLAB\u003dy showed /proc/\u003cpid\u003e/status\nVmSize and VmData wrapping just like in kernel bugzilla #4842, and fixed by\nthis patch - worth including in 2.6.13, though not yet confirmed that it\nfixes that specific report from Frank van Maarseveen.\n\nSigned-off-by: Hugh Dickins \u003chugh@veritas.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n"
    },
    {
      "commit": "7179906293ebdc333f14a03d3e58b03604848f3c",
      "tree": "48623522c6af985400e6181ce1b18d98b910c0fc",
      "parents": [
        "202d182a92c60416680e31baa697faa60b0882f5"
      ],
      "author": {
        "name": "Kirill Korotaev",
        "email": "dev@sw.ru",
        "time": "Mon May 16 21:53:18 2005 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@ppc970.osdl.org",
        "time": "Tue May 17 07:59:12 2005 -0700"
      },
      "message": "[PATCH] mm acct accounting fix\n\nThis patch fixes mm-\u003etotal_vm and mm-\u003elocked_vm acctounting in case when\nmove_page_tables() fails inside move_vma().\n\nSigned-Off-By: Kirill Korotaev \u003cdev@sw.ru\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n"
    },
    {
      "commit": "119f657c72fc07d6fd28c61de59cfba1566970a9",
      "tree": "33c8070aa904c4919cf244cdcd7c01e54589bb9e",
      "parents": [
        "f021e9210185b46e41ec3a0e78ec1621e168eacb"
      ],
      "author": {
        "name": "akpm@osdl.org",
        "email": "akpm@osdl.org",
        "time": "Sun May 01 08:58:35 2005 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@ppc970.osdl.org",
        "time": "Sun May 01 08:58:35 2005 -0700"
      },
      "message": "[PATCH] RLIMIT_AS checking fix\n\nAddress bug #4508: there\u0027s potential for wraparound in the various places\nwhere we perform RLIMIT_AS checking.\n\n(I\u0027m a bit worried about acct_stack_growth().  Are we sure that vma-\u003evm_mm is\nalways equal to current-\u003emm?  If not, then we\u0027re comparing some other\nprocess\u0027s total_vm with the calling process\u0027s rlimits).\n\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"
    }
  ]
}