)]}'
{
  "log": [
    {
      "commit": "e072c6f2af57fb8ad9e0f29bfff3f79edf7bdd55",
      "tree": "9d72262a63754b39df4ebfed5bc74855f0408c3a",
      "parents": [
        "614a7d6a76b7fb37bb399047eb3ccf86cafbf60d"
      ],
      "author": {
        "name": "Bernard Blackham",
        "email": "bernard@blackham.com.au",
        "time": "Sat Apr 16 15:25:45 2005 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@ppc970.osdl.org",
        "time": "Sat Apr 16 15:25:45 2005 -0700"
      },
      "message": "[PATCH] ext2 corruption - regression between 2.6.9 and 2.6.10\n\nWhilst trying to stress test a Promise SX8 card, we stumbled across\nsome nasty filesystem corruption in ext2. Our tests involved\ncreating an ext2 partition, mounting, running several concurrent\nfsx\u0027s over it, umounting, and fsck\u0027ing, all scripted[1]. The fsck\nwould always return with errors.\n\nThis regression was traced back to a change between 2.6.9 and\n2.6.10, which moves the functionality of ext2_put_inode into\next2_clear_inode.  The attached patch reverses this change, and\neliminated the source of corruption.\n\nMingming Cao \u003ccmm@us.ibm.com\u003e said:\n\nI think his patch for ext2 is correct.  The corruption on ext3 is not the same\nissue he saw on ext2.  I believe that\u0027s the race between discard reservation\nand reservation in-use that we already fixed it in 2.6.12- rc1.\n\nFor the problem related to ext2, at the time when we design reservation for\next3, we decide we only need to discard the reservation at the last file\nclose, so we have ext3_discard_reservation on iput_final- \u003eext3_clear_inode.\n\nThe ext2 handle discard preallocation differently at that time, it discard the\npreallocation at each iput(), not in input_final(), so we think it\u0027s\nunnecessary to thrash it so frequently, and the right thing to do, as we did\nfor ext3 reservation, discard preallocation on last iput().  So we moved the\next2_discard_preallocation from ext2_put_inode(0 to ext2_clear_inode.\n\nSince ext2 preallocation is doing pre-allocation on disk, so it is possible\nthat at the unmount time, someone is still hold the reference of the inode, so\nthe preallocation for a file is not discard yet, so we still mark those blocks\nallocated on disk, while they are not actually in the inode\u0027s block map, so\nfsck will catch/fix that error later.\n\nThis is not a issue for ext3, as ext3 reservation(pre-allocation) is done in\nmemory.\n\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n"
    },
    {
      "commit": "e493073d8d053429fbb42331b57a95dd0d61cadb",
      "tree": "c4d697372f6c2f2e2f2548f75c1dbb5b821ab805",
      "parents": [
        "81ddef77bb774e771db8588b937665cd38f40cee"
      ],
      "author": {
        "name": "akpm@osdl.org",
        "email": "akpm@osdl.org",
        "time": "Sat Apr 16 15:24:00 2005 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@ppc970.osdl.org",
        "time": "Sat Apr 16 15:24:00 2005 -0700"
      },
      "message": "[PATCH] Fix acl Oops\n\n\r)\n\n\nFrom: Andreas Gruenbacher \u003cagruen@suse.de\u003e\n\next[23]_get_acl will return an error when reading the attribute fails or\nout-of-memory occurs.  Catch this case.\n\nSigned-off-by: Andreas Gruenbacher \u003cagruen@suse.de\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"
    }
  ]
}