)]}'
{
  "commit": "4b2164d4d212e437c9f080023a67f8f9356d2c4c",
  "tree": "aaa86c0e2b1532b87780f568b35921e56342557d",
  "parents": [
    "0db6f4353d68c0108b5fe0bad8259de0197589c6"
  ],
  "author": {
    "name": "Joe Eykholt",
    "email": "jeykholt@cisco.com",
    "time": "Fri Jun 11 16:44:51 2010 -0700"
  },
  "committer": {
    "name": "James Bottomley",
    "email": "James.Bottomley@suse.de",
    "time": "Tue Jul 27 12:01:52 2010 -0500"
  },
  "message": "[SCSI] libfc: Fix remote port restart problem\n\nThis patch somewhat combines two fixes to remote port handing in libfc.\n\nThe first problem was that rport work could be queued on a deleted\nand freed rport.  This is handled by not resetting rdata-\u003eevent\nton NONE if the rdata is about to be deleted.\n\nHowever, that fix led to the second problem, described by\nBhanu Gollapudi, as follows:\n\u003e Here is the sequence of events. T1 is first LOGO receive thread, T2 is\n\u003e fc_rport_work() scheduled by T1 and T3 is second LOGO receive thread and\n\u003e T4 is fc_rport_work scheduled by T3.\n\u003e\n\u003e 1. (T1)Received 1st LOGO in state Ready\n\u003e 2. (T1)Delete port \u0026 enter to RESTART state.\n\u003e 3. (T1)schdule event_work, since event is RPORT_EV_NONE.\n\u003e 4. (T1)set event \u003d RPORT_EV_LOGO\n\u003e 5. (T1)Enter RESTART state as disc_id is set.\n\u003e 6. (T2)remember to PLOGI, and set event \u003d RPORT_EV_NONE\n\u003e 6. (T3)Received 2nd LOGO\n\u003e 7. (T3)Delete Port \u0026 enter to RESTART state.\n\u003e 8. (T3)schedule event_work, since event is RPORT_EV_NONE.\n\u003e 9. (T3)Enter RESTART state as disc_id is set.\n\u003e 9. (T3)set event \u003d RPORT_EV_LOGO\n\u003e 10.(T2)work restart, enter PLOGI state and issues PLOGI\n\u003e 11.(T4)Since state is not RESTART anymore, restart is not set, and the\n\u003e event is not reset to RPORT_EV_NONE. (current event is RPORT_EV_LOGO).\n\u003e 12. Now, PLOGI succeeds and fc_rport_enter_ready() will not schedule\n\u003e event_work, and hence the rport will never be created, eventually losing\n\u003e the target after dev_loss_tmo.\n\nSo, the problem here is that we were tracking the desire for\nthe rport be restarted by state RESTART, which was otherwise\nequivalent to DELETE.  A contributing factor is that we dropped\nthe lock between steps 6 and 10 in thread T2, which allows the\nstate to change, and we didn\u0027t completely re-evaluate then.\n\nThis is hopefully corrected by the following minor redesign:\n\nSimplify the rport restart logic by making the decision to\nrestart after deleting the transport rport.  That decision\nis based on a new STARTED flag that indicates fc_rport_login()\nhas been called and fc_rport_logoff() has not been called\nsince then.  This replaces the need for the RESTART state.\n\nOnly restart if the rdata is still in DELETED state\nand only if it still has the STARTED flag set.\n\nAlso now, since we clear the event code much later in the\nwork thread, allow for the possibility that the rport may\nhave become READY again via incoming PLOGI, and if so,\nqueue another event to handle that.\n\nIn the problem scenario, the second LOGO received will\ncause the LOGO event to occur again.\n\nReported-by: Bhanu Gollapudi \u003cbprakash@broadcom.com\u003e\nSigned-off-by: Joe Eykholt \u003cjeykholt@cisco.com\u003e\nSigned-off-by: Robert Love \u003crobert.w.love@intel.com\u003e\nSigned-off-by: James Bottomley \u003cJames.Bottomley@suse.de\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "df85e19079fb8f1257bd0699369e0b7d7beb513f",
      "old_mode": 33188,
      "old_path": "drivers/scsi/libfc/fc_rport.c",
      "new_id": "d385efc68c15bb4fb9db13d866f690a68343fcfe",
      "new_mode": 33188,
      "new_path": "drivers/scsi/libfc/fc_rport.c"
    },
    {
      "type": "modify",
      "old_id": "7495c0ba67ee398ceba1ab8fa9e1ed6ce801958d",
      "old_mode": 33188,
      "old_path": "include/scsi/libfc.h",
      "new_id": "db54c4a2d14b128f776c5943c6c83ff136a06f0e",
      "new_mode": 33188,
      "new_path": "include/scsi/libfc.h"
    }
  ]
}