)]}'
{
  "commit": "a0785edff7b316cad566bdc369d3d034c4c1a39c",
  "tree": "5a0b143118c2bb5bb1f9bc8938d8568f7215f562",
  "parents": [
    "79ac6745e4d95cd583bca744d313a323deb4adc2"
  ],
  "author": {
    "name": "James Smart",
    "email": "James.Smart@Emulex.Com",
    "time": "Thu May 11 13:27:09 2006 -0400"
  },
  "committer": {
    "name": "James Bottomley",
    "email": "jejb@mulgrave.il.steeleye.com",
    "time": "Tue Jun 27 10:52:49 2006 -0500"
  },
  "message": "[SCSI] fc transport: resolve scan vs delete deadlocks\n\nIn a prior posting to linux-scsi on the fc transport and workq\ndeadlocks, we noted a second error that did not have a patch:\n  http://marc.theaimsgroup.com/?l\u003dlinux-scsi\u0026m\u003d114467847711383\u0026w\u003d2\n  - There\u0027s a deadlock where scsi_remove_target() has to sit behind\n    scsi_scan_target() due to contention over the scan_lock().\n\nSubsequently we posted a request for comments about the deadlock:\n  http://marc.theaimsgroup.com/?l\u003dlinux-scsi\u0026m\u003d114469358829500\u0026w\u003d2\n\nThis posting resolves the second error. Here\u0027s what we now understand,\nand are implementing:\n\n  If the lldd deletes the rport while a scan is active, the sdev\u0027s queue\n  is blocked which stops the issuing of commands associated with the scan.\n  At this point, the scan stalls, and does so with the shost-\u003escan_mutex held.\n  If, at this point, if any scan or delete request is made on the host, it\n  will stall waiting for the scan_mutex.\n\n  For the FC transport, we queue all delete work to a single workq.\n  So, things worked fine when competing with the scan, as long as the\n  target blocking the scan was the same target at the top of our delete\n  workq, as the delete workq routine always unblocked just prior to\n  requesting the delete.  Unfortunately, if the top of our delete workq\n  was for a different target, we deadlock.  Additionally, if the target\n  blocking scan returned, we were unblocking it in the scan workq routine,\n  which really won\u0027t execute until the existing stalled scan workq\n  completes (e.g. we\u0027re re-scheduling it while it is in the midst of its\n  execution).\n\n  This patch moves the unblock out of the workq routines and moves it to\n  the context that is scheduling the work. This ensures that at some point,\n  we will unblock the target that is blocking scan.  Please note, however,\n  that the deadlock condition may still occur while it waits for the\n  transport to timeout an unblock on a target.  Worst case, this is bounded\n  by the transport dev_loss_tmo (default: 30 seconds).\n\nFinally, Michael Reed deserves the credit for the bulk of this patch,\nanalysis, and it\u0027s testing. Thank you for your help.\n\nNote: The request for comments statements about the gross-ness of the\n  scan_mutex still stand.\n\nSigned-off-by: Michael Reed \u003cmdr@sgi.com\u003e\nSigned-off-by: James Smart \u003cjames.smart@emulex.com\u003e\nSigned-off-by: James Bottomley \u003cJames.Bottomley@SteelEye.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "f2db7a41cf1d4dbbb973eb1ad033dbcaa44183e9",
      "old_mode": 33188,
      "old_path": "drivers/scsi/scsi_transport_fc.c",
      "new_id": "c76e73a3ffbe22b9356f4641c280ded412ff8f66",
      "new_mode": 33188,
      "new_path": "drivers/scsi/scsi_transport_fc.c"
    }
  ]
}