1. 06 Apr, 2017 6 commits
    • Hannes Reinecke's avatar
      scsi: sd: Return SUCCESS in sd_eh_action() after device offline · e8f8d50e
      Hannes Reinecke authored
      If sd_eh_action() decides to take the device offline there is
      no point in returning FAILED, as taking the device offline
      is the ultimate step in SCSI EH anyway.
      So further escalation via SCSI EH is not likely to make a
      difference and we can as well return SUCCESS.
      
      Cc: Benjamin Block <bblock@linux.vnet.ibm.com>
      Signed-off-by: default avatarHannes Reinecke <hare@suse.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      e8f8d50e
    • Hannes Reinecke's avatar
      scsi: scsi_error: count medium access timeout only once per EH run · 7a38dc0b
      Hannes Reinecke authored
      The current medium access timeout counter will be increased for
      each command, so if there are enough failed commands we'll hit
      the medium access timeout for even a single device failure and
      the following kernel message is displayed:
      
      sd H:C:T:L: [sdXY] Medium access timeout failure. Offlining disk!
      
      Fix this by making the timeout per EH run, ie the counter will
      only be increased once per device and EH run.
      
      Fixes: 18a4d0a2 ("[SCSI] Handle disk devices which can not process medium access commands")
      Cc: Ewan Milne <emilne@redhat.com>
      Cc: Lawrence Obermann <loberman@redhat.com>
      Cc: Benjamin Block <bblock@linux.vnet.ibm.com>
      Cc: Steffen Maier <maier@linux.vnet.ibm.com>
      Signed-off-by: default avatarHannes Reinecke <hare@suse.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      7a38dc0b
    • Christoph Hellwig's avatar
      scsi: csiostor: switch to pci_alloc_irq_vectors · 104d9c7f
      Christoph Hellwig authored
      And get automatic MSI-X affinity for free.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Acked-by: default avatarVarun Prakash <varun@chelsio.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      104d9c7f
    • Mauricio Faria de Oliveira's avatar
      scsi: ses: don't get power status of SES device slot on probe · 75106523
      Mauricio Faria de Oliveira authored
      The commit 08024885 ("ses: Add power_status to SES device slot")
      introduced the 'power_status' attribute to enclosure components and
      the associated callbacks.
      
      There are 2 callbacks available to get the power status of a device:
      1) ses_get_power_status() for 'struct enclosure_component_callbacks'
      2) get_component_power_status() for the sysfs device attribute
      (these are available for kernel-space and user-space, respectively.)
      
      However, despite both methods being available to get power status
      on demand, that commit also introduced a call to get power status
      in ses_enclosure_data_process().
      
      This dramatically increased the total probe time for SCSI devices
      on larger configurations, because ses_enclosure_data_process() is
      called several times during the SCSI devices probe and loops over
      the component devices (but that is another problem, another patch).
      
      That results in a tremendous continuous hammering of SCSI Receive
      Diagnostics commands to the enclosure-services device, which does
      delay the total probe time for the SCSI devices __significantly__:
      
        Originally, ~34 minutes on a system attached to ~170 disks:
      
          [ 9214.490703] mpt3sas version 13.100.00.00 loaded
          ...
          [11256.580231] scsi 17:0:177:0: qdepth(16), tagged(1), simple(0),
                         ordered(0), scsi_level(6), cmd_que(1)
      
        With this patch, it decreased to ~2.5 minutes -- a 13.6x faster
      
          [ 1002.992533] mpt3sas version 13.100.00.00 loaded
          ...
          [ 1151.978831] scsi 11:0:177:0: qdepth(16), tagged(1), simple(0),
                         ordered(0), scsi_level(6), cmd_que(1)
      
      Back to the commit discussion.. on the ses_get_power_status() call
      introduced in ses_enclosure_data_process(): impact of removing it.
      
      That may possibly be in place to initialize the power status value
      on device probe.  However, those 2 functions available to retrieve
      that value _do_ automatically refresh/update it.  So the potential
      benefit would be a direct access of the 'power_status' field which
      does not use the callbacks...
      
      But the only reader of 'struct enclosure_component::power_status'
      is the get_component_power_status() callback for sysfs attribute,
      and it _does_ check for and call the .get_power_status callback,
      (which indeed is defined and implemented by that commit), so the
      power status value is, again, automatically updated.
      
      So, the remaining potential for a direct/non-callback access to
      the power_status attribute would be out-of-tree modules -- well,
      for those, if they are for whatever reason interested in values
      that are set during device probe and not up-to-date by the time
      they need it.. well, that would be curious.
      
      Well, to handle that more properly, set the initial power state
      value to '-1' (i.e., uninitialized) instead of '1' (power 'on'),
      and check for it in that callback which may do an direct access
      to the field value _if_ a callback function is not defined.
      Signed-off-by: default avatarMauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
      Fixes: 08024885 ("ses: Add power_status to SES device slot")
      Reviewed-by: default avatarDan Williams <dan.j.williams@intel.com>
      Reviewed-by: default avatarSong Liu <songliubraving@fb.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      75106523
    • Bart Van Assche's avatar
      scsi: Make checking the scsi_device_get() return value mandatory · ed12e031
      Bart Van Assche authored
      Now that all scsi_device_get() callers check the return value of this
      function, make checking that return value mandatory.
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: Johannes Thumshirn <jthumshirn@suse.de>
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      ed12e031
    • Bart Van Assche's avatar
      scsi: osd_uld: Check scsi_device_get() return value · c02465fa
      Bart Van Assche authored
      scsi_device_get() can fail. Hence check its return value.
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Boaz Harrosh <bharrosh@panasas.com>
      Acked-by: default avatarBoaz Harrosh <ooo@electrozaur.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      c02465fa
  2. 05 Apr, 2017 2 commits
  3. 04 Apr, 2017 1 commit
    • Arnd Bergmann's avatar
      scsi: advansys: fix uninitialized data access · 44a5b977
      Arnd Bergmann authored
      gcc-7.0.1 now warns about a previously unnoticed access of uninitialized
      struct members:
      
      drivers/scsi/advansys.c: In function 'AscMsgOutSDTR':
      drivers/scsi/advansys.c:3860:26: error: '*((void *)&sdtr_buf+5)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
               ((ushort)s_buffer[i + 1] << 8) | s_buffer[i]);
                                ^
      drivers/scsi/advansys.c:3860:26: error: '*((void *)&sdtr_buf+7)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      drivers/scsi/advansys.c:3860:26: error: '*((void *)&sdtr_buf+5)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      drivers/scsi/advansys.c:3860:26: error: '*((void *)&sdtr_buf+7)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      
      The code has existed in this exact form at least since v2.6.12, and the
      warning seems correct. This uses named initializers to ensure we
      initialize all members of the structure.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      44a5b977
  4. 30 Mar, 2017 12 commits
  5. 28 Mar, 2017 13 commits
  6. 23 Mar, 2017 6 commits