1. 09 11月, 2016 1 次提交
  2. 19 2月, 2012 1 次提交
  3. 16 1月, 2012 1 次提交
  4. 01 11月, 2011 1 次提交
  5. 28 7月, 2010 1 次提交
  6. 17 5月, 2010 1 次提交
    • R
      [SCSI] libfc: Move the port_id into lport · 7b2787ec
      Robert Love 提交于
      This patch creates a port_id member in struct fc_lport.
      This allows libfc to just deal with fc_lport instances
      instead of calling into the fc_host to get the port_id.
      
      This change helps in only using symbols necessary for
      operation from the libfc structures. libfc still needs
      to change the fc_host_port_id() if the port_id changes
      so the presentation layer (scsi_transport_fc) can provide
      the user with the correct value, but libfc shouldn't
      rely on the presentation layer for operational values.
      Signed-off-by: NRobert Love <robert.w.love@intel.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      7b2787ec
  7. 05 12月, 2009 4 次提交
    • J
      [SCSI] libfc: fix fc_els_resp_type to correct display of CT responses · 52a6690d
      Joe Eykholt 提交于
      Local port debug messages were using fc_els_resp_type() which showed
      all CT responses as rejects.
      
      Handle CT responses correctly based by inspecting fh_type.
      
      I decided not to rename the function to keep the patch smaller.
      We could call it just fc_resp_type() or fc_elsct_resp_type().
      Signed-off-by: NJoe Eykholt <jeykholt@cisco.com>
      Signed-off-by: NRobert Love <robert.w.love@intel.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      52a6690d
    • R
      [SCSI] libfc: Formatting cleanups across libfc · 3a3b42bf
      Robert Love 提交于
      This patch makes a variety of cleanup changes to all libfc files.
      
      This patch adds kernel-doc headers to all functions lacking them
      and attempts to better format existing headers. It also add kernel-doc
      headers to structures.
      
      This patch ensures that the current naming conventions for local ports,
      remote ports and remote port private data is upheld in the following
      manner.
      
      struct               instance (i.e. variable name)
      --------------------------------------------------
      fc_lport                      lport
      fc_rport                      rport
      fc_rport_libfc_priv           rpriv
      fc_rport_priv                 rdata
      
      I also renamed dns_rp and ptp_rp to dns_rdata and ptp_rdata
      respectively.
      
      I used emacs 'indent-region' and 'tabify' on all libfc files
      to correct spacing alignments.
      
      I feel sorry for anyone attempting to review this patch.
      Signed-off-by: NRobert Love <robert.w.love@intel.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      3a3b42bf
    • C
      [SCSI] libfcoe, fcoe: libfcoe NPIV support · 11b56188
      Chris Leech 提交于
      The FIP code in libfcoe needed several changes to support NPIV
      
      1) dst_src_addr needs to be managed per-n_port-ID for FPMA fabrics with NPIV
         enabled.  Managing the MAC address is now handled in fcoe, with some slight
         changes to update_mac() and a new get_src_addr() function pointer.
      
      2) The libfc elsct_send() hook is used to setup FCoE specific response
         handlers for FIP encapsulated ELS exchanges.  This lets the FCoE specific
         handling know which VN_Port the exchange is for, and doesn't require
         tracking OX_IDs.  It might be possible to roll back to the full FIP frame
         in these, but for now I've just stashed the contents of the MAC address
         descriptor in the skb context block for later use.  Also, because
         fcoe_elsct_send() just passes control on to fc_elsct_send(), all transmits
         still come through the normal frame_send() path.
      
      3) The NPIV changes added a mutex hold in the keep alive sending, the lport
         mutex is protecting the vport list.  We can't take a mutex from a timer,
         so move the FIP keep alive logic to the link work struct.
      Signed-off-by: NChris Leech <christopher.leech@intel.com>
      Signed-off-by: NRobert Love <robert.w.love@intel.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      11b56188
    • C
      [SCSI] libfc: fix memory corruption caused by double frees and bad error handling · 8f550f93
      Chris Leech 提交于
      I was running into several different panics under stress, which I traced down
      to a few different possible slab corruption issues in error handling paths.
      I have not yet looked into why these exchange sends fail, but with these
      fixes my test system is much more stable under stress than before.
      
      fc_elsct_send() could fail and either leave the passed in frame intact
      (failure in fc_ct/els_fill) or the frame could have been freed if the
      failure was is fc_exch_seq_send().  The caller had no way of knowing, and
      there was a potential double free in the error handling in fc_fcp_rec().
      
      Make fc_elsct_send() always free the frame before returning, and remove the
      fc_frame_free() call in fc_fcp_rec().
      
      While fc_exch_seq_send() did always consume the frame, there were double free
      bugs in the error handling of fc_fcp_cmd_send() and fc_fcp_srr() as well.
      
      Numerous calls to error handling routines (fc_disc_error(),
      fc_lport_error(), fc_rport_error_retry() ) were passing in a frame pointer that
      had already been freed in the case of an error.  I have changed the call
      sites to pass in a NULL pointer, but there may be more appropriate error
      codes to use.
      
      Question:  Why do these error routines take a frame pointer anyway?  I
      understand passing in a pointer encoded error to the response handlers, but
      the error routines take no action on a valid pointer and should never be
      called that way.
      Signed-off-by: NChris Leech <christopher.leech@intel.com>
      Signed-off-by: NRobert Love <robert.w.love@intel.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      8f550f93
  8. 11 9月, 2009 4 次提交
  9. 27 4月, 2009 1 次提交
  10. 30 12月, 2008 1 次提交
    • R
      [SCSI] libfc: A modular Fibre Channel library · 42e9a92f
      Robert Love 提交于
      libFC is composed of 4 blocks supported by an exchange manager
      and a framing library. The upper 4 layers are fc_lport, fc_disc,
      fc_rport and fc_fcp. A LLD that uses libfc could choose to
      either use libfc's block, or using the transport template
      defined in libfc.h, override one or more blocks with its own
      implementation.
      
      The EM (Exchange Manager) manages exhcanges/sequences for all
      commands- ELS, CT and FCP.
      
      The framing library frames ELS and CT commands.
      
      The fc_lport block manages the library's representation of the
      host's FC enabled ports.
      
      The fc_disc block manages discovery of targets as well as
      handling changes that occur in the FC fabric (via. RSCN events).
      
      The fc_rport block manages the library's representation of other
      entities in the FC fabric. Currently the library uses this block
      for targets, its peer when in point-to-point mode and the
      directory server, but can be extended for other entities if
      needed.
      
      The fc_fcp block interacts with the scsi-ml and handles all
      I/O.
      Signed-off-by: NRobert Love <robert.w.love@intel.com>
      [jejb: added include of delay.h to fix ppc64 compile prob spotted by sfr]
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      42e9a92f