1. 30 Jul, 2015 1 commit
    • Chris Leech's avatar
      iSCSI: let session recovery_tmo sysfs writes persist across recovery · 9c8108a4
      Chris Leech authored
      The iSCSI session recovery_tmo setting is writeable in sysfs, but it's
      also set every time a connection is established when parameters are set
      from iscsid over netlink.  That results in the timeout being reset to
      the default value after every recovery.
      
      The DM multipath tools want to use the sysfs interface to lower the
      default timeout when there are multiple paths to fail over.  It has
      caused confusion that we have a writeable sysfs value that seem to keep
      resetting itself.
      
      This patch adds an in-kernel flag that gets set once a sysfs write
      occurs, and then ignores netlink parameter setting once it's been
      modified via the sysfs interface.  My thinking here is that the sysfs
      interface is much simpler for external tools to influence the session
      timeout, but if we're going to allow it to be modified directly we
      should ensure that setting is maintained.
      Signed-off-by: default avatarChris Leech <cleech@redhat.com>
      Reviewed-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Odin.com>
      9c8108a4
  2. 17 Mar, 2014 1 commit
    • Sagi Grimberg's avatar
      SCSI/libiscsi: Add check_protection callback for transports · 55e51eda
      Sagi Grimberg authored
      iSCSI needs to be at least aware that a task involves protection
      information.  In case it does, after the transaction completed libiscsi
      will ask the transport to check the protection status of the
      transaction.
      
      Unlike transport errors, DIF errors should not prevent successful
      completion of the transaction from the transport point of view, but
      should be escelated to scsi mid-layer when constructing the scsi
      result and sense data.
      
      check_protection routine will return the ascq corresponding to the DIF
      error that occured (or 0 if no error happened).
      
      return ascq:
      - 0x1: GUARD_CHECK_FAILED
      - 0x2: APPTAG_CHECK_FAILED
      - 0x3: REFTAG_CHECK_FAILED
      Signed-off-by: default avatarSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: default avatarAlex Tabachnik <alext@mellanox.com>
      Signed-off-by: default avatarRoland Dreier <roland@purestorage.com>
      55e51eda
  3. 19 Dec, 2013 1 commit
  4. 16 Dec, 2013 1 commit
  5. 25 Oct, 2013 1 commit
  6. 10 May, 2013 1 commit
  7. 11 Apr, 2013 1 commit
  8. 29 Feb, 2012 1 commit
  9. 19 Feb, 2012 3 commits
  10. 03 Jan, 2012 1 commit
  11. 14 Dec, 2011 1 commit
    • Mike Christie's avatar
      [SCSI] iscsi class: export pid of process that created · 0c70d84b
      Mike Christie authored
      There could be multiple userspace entities creating/destroying/
      recoverying sessions and also the kernel's iscsi drivers could
      be doing this too. If the userspace apps do try to manage the kernel
      ones it can get the driver/fw out of sync and cause the user to
      loose the root disk, oopses or ping ponging becasue userspace
      wants to do one thing but the kernel manager thought we
      are trying to do another.
      
      This patch fixes the problem by just exporting the pid of
      the entity that created the session. Userspace programs like
      iscsid, iscsiadm, iscsistart, qlogic's tools, etc, can then
      figure out which sessions they own and only manage them.
      Signed-off-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      0c70d84b
  12. 20 Oct, 2011 2 commits
  13. 27 Aug, 2011 8 commits
  14. 24 Feb, 2011 3 commits
  15. 28 Jul, 2010 1 commit
  16. 09 Jun, 2009 1 commit
  17. 23 May, 2009 1 commit
    • Mike Christie's avatar
      [SCSI] iscsi: pass ep connect shost · 10eb0f01
      Mike Christie authored
      When we create the tcp/ip connection by calling ep_connect, we currently
      just go by the routing table info.
      
      I think there are two problems with this.
      
      1. Some drivers do not have access to a routing table. Some drivers like
      qla4xxx do not even know about other ports.
      
      2. If you have two initiator ports on the same subnet, the user may have
      set things up so that session1 was supposed to be run through port1. and
      session2 was supposed to be run through port2. It looks like we could
      end with both sessions going through one of the ports.
      
      Fixes for cxgb3i from Karen Xie.
      Signed-off-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
      10eb0f01
  18. 13 Mar, 2009 2 commits
  19. 29 Dec, 2008 3 commits
  20. 13 Oct, 2008 2 commits
  21. 21 Jul, 2008 1 commit
  22. 12 Jul, 2008 3 commits