)]}'
{
  "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",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "a76349cb10a53aa571412af63d3115c4242815cc",
      "old_mode": 33188,
      "old_path": "drivers/md/dm-log.c",
      "new_id": "efe4adf7853041bd61c43fcd87488b72a42bbaba",
      "new_mode": 33188,
      "new_path": "drivers/md/dm-log.c"
    }
  ]
}