1. 11 1月, 2017 1 次提交
  2. 16 4月, 2016 2 次提交
  3. 01 6月, 2015 2 次提交
  4. 09 1月, 2015 1 次提交
  5. 25 11月, 2014 2 次提交
  6. 01 10月, 2014 1 次提交
  7. 09 8月, 2014 1 次提交
  8. 26 7月, 2014 1 次提交
  9. 18 7月, 2014 1 次提交
  10. 10 1月, 2014 1 次提交
  11. 10 9月, 2013 1 次提交
  12. 24 8月, 2013 3 次提交
  13. 05 6月, 2013 1 次提交
  14. 20 7月, 2012 1 次提交
  15. 29 6月, 2012 1 次提交
  16. 26 2月, 2012 1 次提交
  17. 21 7月, 2011 1 次提交
    • P
      treewide: fix potentially dangerous trailing ';' in #defined values/expressions · 497888cf
      Phil Carmody 提交于
      All these are instances of
        #define NAME value;
      or
        #define NAME(params_opt) value;
      
      These of course fail to build when used in contexts like
        if(foo $OP NAME)
        while(bar $OP NAME)
      and may silently generate the wrong code in contexts such as
        foo = NAME + 1;    /* foo = value; + 1; */
        bar = NAME - 1;    /* bar = value; - 1; */
        baz = NAME & quux; /* baz = value; & quux; */
      
      Reported on comp.lang.c,
      Message-ID: <ab0d55fe-25e5-482b-811e-c475aa6065c3@c29g2000yqd.googlegroups.com>
      Initial analysis of the dangers provided by Keith Thompson in that thread.
      
      There are many more instances of more complicated macros having unnecessary
      trailing semicolons, but this pile seems to be all of the cases of simple
      values suffering from the problem. (Thus things that are likely to be found
      in one of the contexts above, more complicated ones aren't.)
      Signed-off-by: NPhil Carmody <ext-phil.2.carmody@nokia.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      497888cf
  18. 13 2月, 2011 1 次提交
    • H
      [SCSI] Add detailed SCSI I/O errors · 63583cca
      Hannes Reinecke 提交于
      Instead of just passing 'EIO' for any I/O error we should be
      notifying the upper layers with more details about the cause
      of this error.
      
      Update the possible I/O errors to:
      
      - ENOLINK: Link failure between host and target
      - EIO: Retryable I/O error
      - EREMOTEIO: Non-retryable I/O error
      - EBADE: I/O error restricted to the I_T_L nexus
      
      'Retryable' in this context means that an I/O error _might_ be
      restricted to the I_T_L nexus (vulgo: path), so retrying on another
      nexus / path might succeed.
      
      'Non-retryable' in general refers to a target failure, so this
      error will always be generated regardless of the I_T_L nexus
      it was send on.
      
      I/O errors restricted to the I_T_L nexus might be retried
      on another nexus / path, but they should _not_ be queued
      if no paths are available.
      Signed-off-by: NHannes Reinecke <hare@suse.de>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      63583cca
  19. 25 1月, 2011 1 次提交
  20. 22 12月, 2010 1 次提交
  21. 17 12月, 2010 1 次提交
    • T
      sr: implement sr_check_events() · 93aae17a
      Tejun Heo 提交于
      Replace sr_media_change() with sr_check_events().  It normally only
      uses GET_EVENT_STATUS_NOTIFICATION to check both media change and
      eject request.  If @clearing includes DISK_EVENT_MEDIA_CHANGE, it
      issues TUR and compares whether media presence has changed.  The SCSI
      specific media change uevent is kept for compatibility.
      
      sr_media_change() was doing both media change check and revalidation.
      The revalidation part is split into sr_block_revalidate_disk().
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      93aae17a
  22. 23 10月, 2010 1 次提交
  23. 11 9月, 2010 1 次提交
  24. 11 8月, 2010 1 次提交
  25. 01 5月, 2010 1 次提交
  26. 11 4月, 2010 1 次提交
    • C
      [SCSI] Allow FC LLD to fast-fail scsi eh by introducing new eh return · 2f2eb587
      Christof Schmitt 提交于
      If the scsi eh is running and then a FC LLD calls
      fc_remote_port_delete, the SCSI commands sent from the eh will fail.
      To prevent this, a FC LLD can call fc_block_scsi_eh from the eh
      callback, blocking the eh thread until the dev_loss_tmo fires or the
      remote port is available again.
      
      If (e.g. for a multipathing setup) the dev_loss_tmo is set to a very
      large value, thus preventing the scsi device removal , the scsi eh can
      block for a long time. For multipathing, the fast_io_fail_tmo is then
      set to a low value to detect path problems sooner.
      
      This patch introduces a new return code FAST_IO_FAIL. The function
      fc_block_scsi_eh now returns FAST_IO_FAIL when the fast_io_fail_tmo
      fires. This indicates that the LLD terminated all pending I/O requests
      and there are no more pending SCSI commands for the scsi eh to wait
      for. This return code can be passed back to the scsi eh to stop the
      escalation and finish the recovery process for this device.
      Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      2f2eb587
  27. 05 12月, 2009 1 次提交
  28. 02 10月, 2009 1 次提交
  29. 13 3月, 2009 3 次提交
  30. 13 10月, 2008 2 次提交
    • M
      [SCSI] scsi: add transport host byte errors (v3) · a4dfaa6f
      Mike Christie 提交于
      Currently, if there is a transport problem the iscsi drivers will return
      outstanding commands (commands being exeucted by the driver/fw/hw) with
      DID_BUS_BUSY and block the session so no new commands can be queued.
      Commands that are caught between the failure handling and blocking are
      failed with DID_IMM_RETRY or one of the scsi ml queuecommand return values.
      When the recovery_timeout fires, the iscsi drivers then fail IO with
      DID_NO_CONNECT.
      
      For fcp, some drivers will fail some outstanding IO (disk but possibly not
      tape) with DID_BUS_BUSY or DID_ERROR or some other value that causes a retry
      and hits the scsi_error.c failfast check, block the rport, and commands
      caught in the race are failed with DID_IMM_RETRY. Other drivers, may
      hold onto all IO and wait for the terminate_rport_io or dev_loss_tmo_callbk
      to be called.
      
      The following patches attempt to unify what upper layers will see drivers
      like multipath can make a good guess. This relies on drivers being
      hooked into their transport class.
      
      This first patch just defines two new host byte errors so drivers can
      return the same value for when a rport/session is blocked and for
      when the fast_io_fail_tmo fires.
      
      The idea is that if the LLD/class detects a problem and is going to block
      a rport/session, then if the LLD wants or must return the command to scsi-ml,
      then it can return it with DID_TRANSPORT_DISRUPTED. This will requeue
      the IO into the same scsi queue it came from, until the fast io fail timer
      fires and the class decides what to do.
      
      When using multipath and the fast_io_fail_tmo fires then the class
      can fail commands with DID_TRANSPORT_FAILFAST or drivers can use
      DID_TRANSPORT_FAILFAST in their terminate_rport_io callbacks or
      the equivlent in iscsi if we ever implement more advanced recovery methods.
      A LLD, like lpfc, could continue to return DID_ERROR and then it will hit
      the normal failfast path, so drivers do not have fully be ported to
      work better. The point of the patches is that upper layers will
      not see a failure that could be recovered from while the rport/session is
      blocked until fast_io_fail_tmo/recovery_timeout fires.
      
      V3
      Remove some comments.
      V2
      Fixed patch/diff errors and renamed DID_TRANSPORT_BLOCKED to
      DID_TRANSPORT_DISRUPTED.
      V1
      initial patch.
      Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      a4dfaa6f
    • M
      [SCSI] Add helper code so transport classes/driver can control queueing (v3) · f0c0a376
      Mike Christie 提交于
      SCSI-ml manages the queueing limits for the device and host, but
      does not do so at the target level. However something something similar
      can come in userful when a driver is transitioning a transport object to
      the the blocked state, becuase at that time we do not want to queue
      io and we do not want the queuecommand to be called again.
      
      The patch adds code similar to the exisiting SCSI_ML_*BUSY handlers.
      You can now return SCSI_MLQUEUE_TARGET_BUSY when we hit
      a transport level queueing issue like the hw cannot allocate some
      resource at the iscsi session/connection level, or the target has temporarily
      closed or shrunk the queueing window, or if we are transitioning
      to the blocked state.
      
      bnx2i, when they rework their firmware according to netdev
      developers requests, will also need to be able to limit queueing at this
      level. bnx2i will hook into libiscsi, but will allocate a scsi host per
      netdevice/hba, so unlike pure software iscsi/iser which is allocating
      a host per session, it cannot set the scsi_host->can_queue and return
      SCSI_MLQUEUE_HOST_BUSY to reflect queueing limits on the transport.
      
      The iscsi class/driver can also set a scsi_target->can_queue value which
      reflects the max commands the driver/class can support. For iscsi this
      reflects the number of commands we can support for each session due to
      session/connection hw limits, driver limits, and to also reflect the
      session/targets's queueing window.
      
      Changes:
      v1 - initial patch.
      v2 - Fix scsi_run_queue handling of multiple blocked targets.
      Previously we would break from the main loop if a device was added back on
      the starved list. We now run over the list and check if any target is
      blocked.
      v3 - Rediff for scsi-misc.
      Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      f0c0a376
  31. 29 8月, 2008 1 次提交
  32. 27 7月, 2008 1 次提交