1. 20 Jul, 2016 1 commit
  2. 24 Nov, 2014 1 commit
  3. 12 Nov, 2014 1 commit
  4. 04 Sep, 2013 1 commit
    • Bart Van Assche's avatar
      libfc: Do not invoke the response handler after fc_exch_done() · 7030fd62
      Bart Van Assche authored
      While the FCoE initiator driver invokes fc_exch_done() from inside
      the libfc response handler, FCoE target drivers typically invoke
      fc_exch_done() from outside the libfc response handler. The object
      fc_exch.arg points at may disappear as soon as fc_exch_done() has
      finished. So it's important not to invoke the response handler
      function after fc_exch_done() has finished. Modify libfc such that
      this guarantee is provided if fc_exch_done() is invoked from
      outside a response handler. This patch fixes a sporadic crash in
      FCoE target implementations after a command has been aborted.
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarRobert Love <robert.w.love@intel.com>
  5. 25 Mar, 2013 2 commits
  6. 20 Jul, 2012 3 commits
  7. 19 Feb, 2012 1 commit
    • Neerav Parikh's avatar
      [SCSI] libfc: Add support for FDMI · d78c317f
      Neerav Parikh authored
      This patch adds support for Fabric Device Management
      Interface as per FC-GS-4 spec. in libfc. Any driver
      making use of libfc can enable fdmi state machine
      for a given lport.
      If lport has enabled FDMI support the lport state
      machine will transition into FDMI after completing
      the DNS states and before entering the SCR state.
      The FDMI state transition is such that if there is an
      error, it won't stop the lport state machine from
      transitioning and the it will behave as if there was
      no FDMI support.
      The FDMI HBA attributes are registed with the Management
      server via Register HBA (RHBA) command and the port
      attributes are reigstered using the Register Port(RPA)
      Signed-off-by: default avatarNeerav Parikh <neerav.parikh@intel.com>
      Tested-by: default avatarRoss Brattain <ross.b.brattain@intel.com>
      Acked-by: default avatarRobert Love <robert.w.love@intel.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
  8. 16 Jan, 2012 1 commit
  9. 02 Oct, 2011 2 commits
  10. 29 Jun, 2011 1 commit
  11. 31 Mar, 2011 1 commit
  12. 12 Feb, 2011 6 commits
  13. 21 Dec, 2010 2 commits
  14. 16 Nov, 2010 1 commit
    • Jeff Garzik's avatar
      SCSI host lock push-down · f281233d
      Jeff Garzik authored
      Move the mid-layer's ->queuecommand() invocation from being locked
      with the host lock to being unlocked to facilitate speeding up the
      critical path for drivers who don't need this lock taken anyway.
      The patch below presents a simple SCSI host lock push-down as an
      equivalent transformation.  No locking or other behavior should change
      with this patch.  All existing bugs and locking orders are preserved.
      Additionally, add one parameter to queuecommand,
      	struct Scsi_Host *
      and remove one parameter from queuecommand,
      	void (*done)(struct scsi_cmnd *)
      Scsi_Host* is a convenient pointer that most host drivers need anyway,
      and 'done' is redundant to struct scsi_cmnd->scsi_done.
      Minimal code disturbance was attempted with this change.  Most drivers
      needed only two one-line modifications for their host lock push-down.
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      Acked-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  15. 25 Oct, 2010 1 commit
    • Bhanu Prakash Gollapudi's avatar
      [SCSI] libfc: Do not let disc work cancel itself · c531b9b4
      Bhanu Prakash Gollapudi authored
      When number of NPIV ports created are greater than the xids
      allocated per pool -- for eg., creating 255 NPIV ports on a
      system with nr_cpu_ids of 32, with each pool containing 128
      xids -- and then generating a link event - for eg.,
      shutdown/no shutdown -- on the switch port causes the hang
      with the following stack trace.
      Call Trace:
      fc_disc_stop+0x16/0x30 [libfc]
      fc_lport_reset_locked+0x47/0x90 [libfc]
      fc_lport_enter_reset+0x67/0xe0 [libfc]
      fc_lport_disc_callback+0xbc/0xe0 [libfc]
      fc_disc_done+0xa8/0xf0 [libfc]
      fc_disc_timeout+0x29/0x40 [libfc]
      Fix is to not cancel the disc_work if discovery is already
      stopped, thus allowing lport state machine to restart and try
      discovery again.
      Signed-off-by: default avatarBhanu Prakash Gollapudi <bprakash@broadcom.com>
      Acked-by: default avatarJoe Eykholt <jeykholt@cisco.com>
      Signed-off-by: default avatarRobert Love <robert.w.love@intel.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
  16. 28 Jul, 2010 11 commits
  17. 27 Jul, 2010 2 commits
    • Joe Eykholt's avatar
      [SCSI] libfc: fix indefinite rport restart · f034260d
      Joe Eykholt authored
      Remote ports were restarting indefinitely after getting
      rejects in PRLI.
      Fix by adding a counter of restarts and limiting that with
      the port login retry limit as well.
      Signed-off-by: default avatarJoe Eykholt <jeykholt@cisco.com>
      Signed-off-by: default avatarRobert Love <robert.w.love@intel.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
    • Joe Eykholt's avatar
      [SCSI] libfc: Fix remote port restart problem · 4b2164d4
      Joe Eykholt authored
      This patch somewhat combines two fixes to remote port handing in libfc.
      The first problem was that rport work could be queued on a deleted
      and freed rport.  This is handled by not resetting rdata->event
      ton NONE if the rdata is about to be deleted.
      However, that fix led to the second problem, described by
      Bhanu Gollapudi, as follows:
      > Here is the sequence of events. T1 is first LOGO receive thread, T2 is
      > fc_rport_work() scheduled by T1 and T3 is second LOGO receive thread and
      > T4 is fc_rport_work scheduled by T3.
      > 1. (T1)Received 1st LOGO in state Ready
      > 2. (T1)Delete port & enter to RESTART state.
      > 3. (T1)schdule event_work, since event is RPORT_EV_NONE.
      > 4. (T1)set event = RPORT_EV_LOGO
      > 5. (T1)Enter RESTART state as disc_id is set.
      > 6. (T2)remember to PLOGI, and set event = RPORT_EV_NONE
      > 6. (T3)Received 2nd LOGO
      > 7. (T3)Delete Port & enter to RESTART state.
      > 8. (T3)schedule event_work, since event is RPORT_EV_NONE.
      > 9. (T3)Enter RESTART state as disc_id is set.
      > 9. (T3)set event = RPORT_EV_LOGO
      > 10.(T2)work restart, enter PLOGI state and issues PLOGI
      > 11.(T4)Since state is not RESTART anymore, restart is not set, and the
      > event is not reset to RPORT_EV_NONE. (current event is RPORT_EV_LOGO).
      > 12. Now, PLOGI succeeds and fc_rport_enter_ready() will not schedule
      > event_work, and hence the rport will never be created, eventually losing
      > the target after dev_loss_tmo.
      So, the problem here is that we were tracking the desire for
      the rport be restarted by state RESTART, which was otherwise
      equivalent to DELETE.  A contributing factor is that we dropped
      the lock between steps 6 and 10 in thread T2, which allows the
      state to change, and we didn't completely re-evaluate then.
      This is hopefully corrected by the following minor redesign:
      Simplify the rport restart logic by making the decision to
      restart after deleting the transport rport.  That decision
      is based on a new STARTED flag that indicates fc_rport_login()
      has been called and fc_rport_logoff() has not been called
      since then.  This replaces the need for the RESTART state.
      Only restart if the rdata is still in DELETED state
      and only if it still has the STARTED flag set.
      Also now, since we clear the event code much later in the
      work thread, allow for the possibility that the rport may
      have become READY again via incoming PLOGI, and if so,
      queue another event to handle that.
      In the problem scenario, the second LOGO received will
      cause the LOGO event to occur again.
      Reported-by: default avatarBhanu Gollapudi <bprakash@broadcom.com>
      Signed-off-by: default avatarJoe Eykholt <jeykholt@cisco.com>
      Signed-off-by: default avatarRobert Love <robert.w.love@intel.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
  18. 16 May, 2010 2 commits