)]}'
{
  "log": [
    {
      "commit": "1113a7e92e483074c6235da59460759e33b9b144",
      "tree": "632a2eded0668e9ce925ccae721feaf387364cff",
      "parents": [
        "35849c75d7750a254119c1a4b88c90156919df2a"
      ],
      "author": {
        "name": "Stefan Bader",
        "email": "shbader@de.ibm.com",
        "time": "Thu Feb 02 14:28:07 2006 -0800"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@g5.osdl.org",
        "time": "Thu Feb 02 15:07:13 2006 -0800"
      },
      "message": "[PATCH] device-mapper log bitset: fix big endian find_next_zero_bit\n\nThis is a fix to the device-mapper-log-bitset-fix-endian patch that\nswitched to ext2_* versions of the set and clear bit functions.  The\nfind_next_zero_bit function also has to be the ext2 one.  Otherwise the\nmirror target tries to recover non-existent regions beyond the end of\ndevice.\n\nSigned-off-by: Stefan Bader \u003cshbader@de.ibm.com\u003e\nSigned-off-by: Alasdair G Kergon \u003cagk@redhat.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n"
    },
    {
      "commit": "a4fc4717fc55a3bcd3cfdafa285b7af164b83051",
      "tree": "bce42a0cc5a6675ab50fb6b525e4418b66863fdf",
      "parents": [
        "aa14edeb994f8f7e223d02ad14780bf2fa719f6d"
      ],
      "author": {
        "name": "Patrick Caulfield",
        "email": "pcaulfie@redhat.com",
        "time": "Wed Feb 01 03:04:51 2006 -0800"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@g5.osdl.org",
        "time": "Wed Feb 01 08:53:10 2006 -0800"
      },
      "message": "[PATCH] device-mapper log bitset: fix endian\n\nClean up the code responsible for the on-disk mirror logs by using the\nset_le_bit test_le_bit functions of ext2.  That makes the BE machines keep the\nbitmap internally in LE order - it does mean you can\u0027t use any other type of\noperations on the bitmap words but that looks to be OK in this instance.  The\nefficiency tradeoff is very minimal as you would expect for something that\next2 uses.\n\nThis allows us to remove bits_to_core(), bits_to_disk() and log-\u003edisk_bits.\n\nAlso increment the mirror log disk version transparently to avoid sharing with\nolder kernels that suffered from the 64-bit BE bug.\n\nSigned-off-by: Patrick Caulfield \u003cpcaulfie@redhat.com\u003e\nSigned-off-by: Alasdair G Kergon \u003cagk@redhat.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n"
    },
    {
      "commit": "ac81b2ee45eb811fdb0aa1cfb71d468d944d00ce",
      "tree": "68ec667534f7669e60aadc09115f67fb0caf5fbe",
      "parents": [
        "9d3520a339d62f942085e9888f66905eb8b350bd"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@us.ibm.com",
        "time": "Fri Jan 06 00:20:11 2006 -0800"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@g5.osdl.org",
        "time": "Fri Jan 06 08:34:01 2006 -0800"
      },
      "message": "[PATCH] make dm-mirror not issue invalid resync requests\n\nI\u0027ve been attempting to set up a (Host)RAID mirror with dm_mirror on\n2.6.14.3, and I\u0027ve been having a strange little problem.  The configuration\nin question is a set of 9GB SCSI disks that have 17942584 sectors.  I set\nup the dm_mirror table as such:\n\n0 17942528 mirror core 2 2048 nosync 2 8:48 0 8:64 0\n\nIf I\u0027m not mistaken, this sets up a 9GB RAID1 mriror with 1MB stripes\nacross both SCSI disks.  The sector count of the dm device is less than the\nsize of the disks, so we shouldn\u0027t fall off the end.  However, I always get\nthe messages like this in dmesg when I set up the dm table:\n\nattempt to access beyond end of device\nsdd: rw\u003d0, want\u003d17958656, limit\u003d17942584\n\nClearly, something is trying to read sectors past the end of the drive.  I\ntraced it down to the __rh_recovery_prepare function in dm-raid1.c, which\ngets called when we\u0027re putting the mirror set together.  This function\ncalls the dirty region log\u0027s get_resync_work function to see if there\u0027s any\nresync that needs to be done, and queues up any areas that are out of sync.\n The log\u0027s get_resync_work function is actually a pointer to the\ncore_get_resync_work function in dm-log.c.\n\nThe core_get_resync_work function queries a bitset lc-\u003esync_bits to find\nout if there are any regions that are out of date (i.e.  the bit is 0),\nwhich is where the problem occurs.  If every bit in lc-\u003esync_bits is 1\n(which is the case when we\u0027ve just configured a new RAID1 with the nosync\noption), the find_next_zero_bit does NOT return the size parameter\n(lc-\u003eregion_count in this case), it returns the size parameter rounded up\nto the nearest multiple of 32!  I don\u0027t know if this is intentional, but\ni386 and x86_64 both exhibit this behavior.\n\nIn any case, the statement \"if (*region \u003d\u003d lc-\u003eregion_count)\" looks like\nit\u0027s supposed to catch the case where are no regions to resync and\nreturn 0.  Since find_next_zero_bit apparently has a habit of returning\na value that\u0027s larger than lc-\u003eregion_count, the enclosed patch changes\nthe equality test to a greater-than test so that we don\u0027t try to resync\nareas outside of the RAID1 region.  Seeing as the HostRAID metadata\nlives just past the end of the RAID1 data, mucking around in that area\nis not a good idea.\n\nI suppose another way to fix this would be to amend find_next_zero_bit so\nthat it doesn\u0027t return values larger than \"size\", but I don\u0027t know if\nthere\u0027s a reason for the current behavior.\n\nSigned-Off-By: Darrick J. Wong \u003cdjwong@us.ibm.com\u003e\nAcked-by: Alasdair G Kergon \u003cagk@redhat.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n"
    },
    {
      "commit": "0e56822d30184d0da35a6ecc51f38c4ceb457a80",
      "tree": "a9ee18ce0e724f16dde3c5c97af67fb3a92701f7",
      "parents": [
        "c4cc66351a24da5feec298be2da59a85f68dd3ea"
      ],
      "author": {
        "name": "Alasdair G Kergon",
        "email": "agk@redhat.com",
        "time": "Mon Nov 21 21:32:34 2005 -0800"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@g5.osdl.org",
        "time": "Tue Nov 22 09:14:31 2005 -0800"
      },
      "message": "[PATCH] device-mapper: mirror log bitset fix\n\nThe linux bitset operators (test_bit, set_bit etc) work on arrays of \"unsigned\nlong\".  dm-log uses such bitsets but treats them as arrays of uint32_t, only\nallocating and zeroing a multiple of 4 bytes (as \u0027clean_bits\u0027 is a uint32_t).\n\nThe patch below fixes this problem.\n\nThe problem is specific to 64-bit big endian machines such as s390x or ppc-64\nand can prevent pvmove terminating.\n\nIn the simplest case, if \"region_count\" were (say) 30, then\nbitset_size (below) would be 4 and bitset_uint32_count would be 1.\nThus the memory for this butset, after allocation and zeroing would\nbe\n   0 0 0 0 X X X X\nOn a bigendian 64bit machine, bit 0 for this bitset is in the 8th\nbyte! (and every bit that dm-log would use would be in the X area).\n\n   0 0 0 0 X X X X\n                 ^\n                 here\n\nwhich hasn\u0027t been cleared properly.\n\nAs the dm-raid1 code only syncs and counts regions which have a 0 in the\n\u0027sync_bits\u0027 bitset, and only finishes when it has counted high enough, a large\nnumber of 1\u0027s among those \u0027X\u0027s will cause the sync to not complete.\n\nIt is worth noting that the code uses the same bitsets for in-memory and\non-disk logs.  As these bitsets are host-endian and host-sized, this means\nthat they cannot safely be moved between computers with\n\nSigned-off-by: Neil Brown \u003cneilb@suse.de\u003e\nSigned-off-by: Alasdair G Kergon \u003cagk@redhat.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"
    }
  ]
}