1. 12 Feb, 2011 2 commits
    • Joe Eykholt's avatar
      [SCSI] libfc: add method for setting handler for incoming exchange · 1a5c2d7e
      Joe Eykholt authored
      Add a method for setting handler for incoming exchange.
      For multi-sequence exchanges, this allows the target driver
      to add a response handler for handling subsequent sequences,
      and exchange manager resets.
      
      The new function is called fc_seq_set_resp().
      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>
      1a5c2d7e
    • Joe Eykholt's avatar
      [SCSI] libfc: add hook for FC-4 provider registration · 96ad8464
      Joe Eykholt authored
      Allow FC-4 provider modules to hook into libfc, mostly for targets.
      This should allow any FC-4 module to handle PRLI requests and maintain
      process-association states.
      
      Each provider registers its ops with libfc and then will be called for
      any incoming PRLI for that FC-4 type on any instance.   The provider
      can decide whether to handle that particular instance using any method
      it likes, such as ACLs or other configuration information.
      
      A count is kept of the number of successful PRLIs from the remote port.
      Providers are called back with an implicit PRLO when the remote port
      is about to be deleted or has been reset.
      
      fc_lport_recv_req() now sends incoming FC-4 requests to FC-4 providers,
      and there is a built-in provider always registered for handling
      incoming ELS requests.
      
      The call to provider recv() routines uses rcu_read_lock()
      so that providers aren't removed during the call.  That lock is very
      cheap and shouldn't affect any performance on ELS requests.
      Providers can rely on the RCU lock to protect a session lookup 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>
      96ad8464
  2. 21 Dec, 2010 2 commits
  3. 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>
      f281233d
  4. 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:
      schedule_timeout+0x19d/0x230
      wait_for_common+0xc0/0x170
      __cancel_work_timer+0xcf/0x1b0
      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]
      run_workqueue+0xb8/0x140
      worker_thread+0x96/0x110
      kthread+0x96/0xa0
      child_rip+0xa/0x20
      
      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>
      c531b9b4
  5. 28 Jul, 2010 11 commits
  6. 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>
      f034260d
    • 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>
      4b2164d4
  7. 16 May, 2010 2 commits
  8. 11 Apr, 2010 2 commits
    • Joe Eykholt's avatar
      [SCSI] libfc: fix hton24 macro to take expressions as args · 0b2f74a4
      Joe Eykholt authored
      hton24(p + 3, value) would fail to compile because
      p + 3[0] is not a valid expression.
      
      Went ahead and converted hton24 and ntoh24 to inline
      functions, which is better because the parameters
      are evalutated only once.
      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>
      0b2f74a4
    • Joe Eykholt's avatar
      [SCSI] libfc, libfcoe, fcoe: use smp_processor_id() only when preempt disabled · f018b73a
      Joe Eykholt authored
      When the kernel is configured for preemption, using smp_processor_id()
      when preemption is enabled causes a warning backtrace and is wrong
      since we could move off of that CPU as soon as we get the ID,
      and we would be referencing the wrong CPU, and possibly an invalid one
      if it could be hotswapped out.
      
      Remove the fc_lport_get_stats() function and explicitly use per_cpu_ptr()
      to get the statistics.  Where preemption has been disabled by holding
      a _bh lock continue to use smp_processor_id(), but otherwise use
      get_cpu()/put_cpu().
      
      In fcoe_recv_frame() also changed the cases where we return in the
      middle to do a goto to the code which bumps ErrorFrames and does
      a put_cpu().  Two of these cases didn't bump ErrorFrames before, but
      doing so is harmless because they "can't happen", due to prior length
      checks.
      
      Also rearranged code in fcoe_recv_frame() to have only one call to
      fc_exch_recv().  It's just as efficient and saves a call to put_cpu().
      
      In fc_fcp.c, adjusted a FIXME comment for code which doesn't need fixing.
      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>
      f018b73a
  9. 04 Dec, 2009 17 commits