1. 15 Apr, 2016 2 commits
  2. 11 Apr, 2016 2 commits
  3. 05 Apr, 2016 1 commit
  4. 18 Mar, 2016 1 commit
    • Arnd Bergmann's avatar
      scsi: fc: use get/put_unaligned64 for wwn access · ef3fb242
      Arnd Bergmann authored
      A bug in the gcc-6.0 prerelease version caused at least one
      driver (lpfc) to have excessive stack usage when dealing with
      wwn data, on the ARM architecture.
      
      lpfc_scsi.c: In function 'lpfc_find_next_oas_lun':
      lpfc_scsi.c:117:1: warning: the frame size of 1152 bytes is larger than 1024 bytes [-Wframe-larger-than=]
      
      I have reported this as a gcc regression in
      https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
      
      However, using a better implementation of wwn_to_u64() not only
      helps with the particular gcc problem but also leads to better
      object code for any version or architecture.
      
      The kernel already provides get_unaligned_be64() and
      put_unaligned_be64() helper functions that provide an
      optimized implementation with the desired semantics.
      
      The lpfc_find_next_oas_lun() function in the example that
      grew from 1146 bytes to 5144 bytes when moving from gcc-5.3
      to gcc-6.0 is now 804 bytes, as the optimized
      get_unaligned_be64() load can be done in three instructions.
      The stack usage is now down to 28 bytes from 128 bytes with
      gcc-5.3 before.
      Signed-off-by: 's avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: 's avatarHannes Reinicke <hare@suse.de>
      Reviewed-by: 's avatarEwan Milne <emilne@redhat.com>
      Signed-off-by: 's avatarMartin K. Petersen <martin.petersen@oracle.com>
      ef3fb242
  5. 05 Mar, 2016 1 commit
  6. 23 Feb, 2016 5 commits
  7. 27 Jan, 2016 1 commit
  8. 23 Dec, 2015 1 commit
  9. 18 Dec, 2015 2 commits
  10. 02 Dec, 2015 3 commits
  11. 30 Nov, 2015 1 commit
  12. 25 Nov, 2015 1 commit
  13. 19 Nov, 2015 1 commit
  14. 09 Nov, 2015 1 commit
  15. 28 Aug, 2015 5 commits
  16. 26 Aug, 2015 1 commit
  17. 03 Aug, 2015 1 commit
  18. 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: 's avatarChris Leech <cleech@redhat.com>
      Reviewed-by: 's avatarMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: 's avatarJames Bottomley <JBottomley@Odin.com>
      9c8108a4
  19. 23 Jul, 2015 2 commits
  20. 14 Jul, 2015 1 commit
  21. 01 Jun, 2015 2 commits
  22. 18 May, 2015 1 commit
    • Bart Van Assche's avatar
      IB/srp: Add 64-bit LUN support · 985aa495
      Bart Van Assche authored
      The SCSI standard defines 64-bit values for LUNs. Large arrays
      employing large or hierarchical LUN numbers become more and more
      common. So update the SRP initiator to use 64-bit LUN numbers.
      See also Hannes Reinecke, commit 9cb78c16 ("scsi: use 64-bit LUNs"),
      June 2014.
      
      The largest LUN number that has been tested is 0xd2003fff00000000.
      
      Checked the following structure sizes with gdb:
      * sizeof(struct srp_cmd) = 48
      * sizeof(struct srp_tsk_mgmt) = 48
      * sizeof(struct srp_aer_req) = 36
      
      The ibmvscsi changes have been compile tested only (on a PPC system).
      Signed-off-by: 's avatarBart Van Assche <bart.vanassche@sandisk.com>
      Reviewed-by: 's avatarHannes Reinecke <hare@suse.de>
      Reviewed-by: 's avatarSagi Grimberg <sagig@mellanox.com>
      Reviewed-by: 's avatarYann Droneaud <ydroneaud@opteya.com>
      Cc: Sebastian Parschauer <sebastian.riemer@profitbricks.com>
      Cc: Brian King <brking@linux.vnet.ibm.com>
      Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com>
      Cc: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
      Signed-off-by: 's avatarDoug Ledford <dledford@redhat.com>
      985aa495
  23. 27 Apr, 2015 1 commit
    • Mike Christie's avatar
      SCSI: add 1024 max sectors black list flag · 35e9a9f9
      Mike Christie authored
      This works around a issue with qnap iscsi targets not handling large IOs
      very well.
      
      The target returns:
      
      VPD INQUIRY: Block limits page (SBC)
        Maximum compare and write length: 1 blocks
        Optimal transfer length granularity: 1 blocks
        Maximum transfer length: 4294967295 blocks
        Optimal transfer length: 4294967295 blocks
        Maximum prefetch, xdread, xdwrite transfer length: 0 blocks
        Maximum unmap LBA count: 8388607
        Maximum unmap block descriptor count: 1
        Optimal unmap granularity: 16383
        Unmap granularity alignment valid: 0
        Unmap granularity alignment: 0
        Maximum write same length: 0xffffffff blocks
        Maximum atomic transfer length: 0
        Atomic alignment: 0
        Atomic transfer length granularity: 0
      
      and it is *sometimes* able to handle at least one IO of size up to 8 MB. We
      have seen in traces where it will sometimes work, but other times it
      looks like it fails and it looks like it returns failures if we send
      multiple large IOs sometimes. Also it looks like it can return 2 different
      errors. It will sometimes send iscsi reject errors indicating out of
      resources or it will send invalid cdb illegal requests check conditions.
      And then when it sends iscsi rejects it does not seem to handle retries
      when there are command sequence holes, so I could not just add code to
      try and gracefully handle that error code.
      
      The problem is that we do not have a good contact for the company,
      so we are not able to determine under what conditions it returns
      which error and why it sometimes works.
      
      So, this patch just adds a new black list flag to set targets like this to
      the old max safe sectors of 1024. The max_hw_sectors changes added in 3.19
      caused this regression, so I also ccing stable.
      Reported-by: 's avatarChristian Hesse <list@eworm.de>
      Signed-off-by: 's avatarMike Christie <michaelc@cs.wisc.edu>
      Cc: stable@vger.kernel.org
      Reviewed-by: 's avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: 's avatarJames Bottomley <JBottomley@Odin.com>
      35e9a9f9
  24. 10 Apr, 2015 1 commit
  25. 27 Mar, 2015 1 commit