1. 07 11月, 2015 1 次提交
  2. 07 9月, 2015 1 次提交
  3. 29 8月, 2015 1 次提交
  4. 27 8月, 2015 1 次提交
  5. 26 8月, 2015 1 次提交
  6. 03 8月, 2015 1 次提交
  7. 31 7月, 2015 1 次提交
    • T
      scsi: fix memory leak with scsi-mq · 0c958ecc
      Tony Battersby 提交于
      Fix a memory leak with scsi-mq triggered by commands with large data
      transfer length.
      
      __sg_alloc_table() sets both table->nents and table->orig_nents to the
      same value.  When the scatterlist is DMA-mapped, table->nents is
      overwritten with the (possibly smaller) size of the DMA-mapped
      scatterlist, while table->orig_nents retains the original size of the
      allocated scatterlist.  scsi_free_sgtable() should therefore check
      orig_nents instead of nents, and all code that initializes sdb->table
      without calling __sg_alloc_table() should set both nents and orig_nents.
      
      Fixes: d285203c ("scsi: add support for a blk-mq based I/O path.")
      Cc: <stable@vger.kernel.org> # 3.17+
      Signed-off-by: NTony Battersby <tonyb@cybernetics.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NEwan D. Milne <emilne@redhat.com>
      Signed-off-by: NJames Bottomley <JBottomley@Odin.com>
      0c958ecc
  8. 24 7月, 2015 1 次提交
  9. 01 6月, 2015 1 次提交
  10. 27 3月, 2015 1 次提交
  11. 09 1月, 2015 2 次提交
  12. 31 12月, 2014 1 次提交
  13. 25 11月, 2014 1 次提交
  14. 24 11月, 2014 2 次提交
  15. 12 11月, 2014 7 次提交
  16. 10 11月, 2014 2 次提交
  17. 16 9月, 2014 1 次提交
  18. 29 8月, 2014 1 次提交
    • J
      block,scsi: fixup blk_get_request dead queue scenarios · a492f075
      Joe Lawrence 提交于
      The blk_get_request function may fail in low-memory conditions or during
      device removal (even if __GFP_WAIT is set). To distinguish between these
      errors, modify the blk_get_request call stack to return the appropriate
      ERR_PTR. Verify that all callers check the return status and consider
      IS_ERR instead of a simple NULL pointer check.
      
      For consistency, make a similar change to the blk_mq_alloc_request leg
      of blk_get_request.  It may fail if the queue is dead, or the caller was
      unwilling to wait.
      Signed-off-by: NJoe Lawrence <joe.lawrence@stratus.com>
      Acked-by: Jiri Kosina <jkosina@suse.cz> [for pktdvd]
      Acked-by: Boaz Harrosh <bharrosh@panasas.com> [for osd]
      Reviewed-by: NJeff Moyer <jmoyer@redhat.com>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      a492f075
  19. 27 8月, 2014 1 次提交
  20. 25 7月, 2014 1 次提交
  21. 18 7月, 2014 2 次提交
  22. 24 6月, 2014 2 次提交
  23. 06 6月, 2014 1 次提交
    • J
      block: add blk_rq_set_block_pc() · f27b087b
      Jens Axboe 提交于
      With the optimizations around not clearing the full request at alloc
      time, we are leaving some of the needed init for REQ_TYPE_BLOCK_PC
      up to the user allocating the request.
      
      Add a blk_rq_set_block_pc() that sets the command type to
      REQ_TYPE_BLOCK_PC, and properly initializes the members associated
      with this type of request. Update callers to use this function instead
      of manipulating rq->cmd_type directly.
      
      Includes fixes from Christoph Hellwig <hch@lst.de> for my half-assed
      attempt.
      Signed-off-by: NJens Axboe <axboe@fb.com>
      f27b087b
  24. 19 5月, 2014 2 次提交
  25. 22 4月, 2014 4 次提交
    • J
      [SCSI] More USB deadlock fixes · c69e6f81
      James Bottomley 提交于
      This patch fixes a corner case in the previous USB Deadlock fix patch (12023e7
      [SCSI] Fix USB deadlock caused by SCSI error handling).
      
      The scenario is abort command, set flag, abort completes, send TUR, TUR
      doesn't return, so we now try to abort the TUR, but scsi_abort_eh_cmnd()
      will skip the abort because the flag is set and move straight to reset.
      Reviewed-by: NHannes Reinecke <hare@suse.de>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      c69e6f81
    • H
      [SCSI] Fix USB deadlock caused by SCSI error handling · 7daf4804
      Hannes Reinecke 提交于
      USB requires that every command be aborted first before we escalate to reset.
      In particular, USB will deadlock if we try to reset first before aborting the
      command.
      
      Unfortunately, the flag we use to tell if a command has already been aborted:
      SCSI_EH_ABORT_SCHEDULED is not cleared properly leading to cases where we can
      requeue a command with the flag set and proceed immediately to reset if it
      fails (thus causing USB to deadlock).
      
      Fix by clearing the SCSI_EH_ABORT_SCHEDULED flag if it has been set.  Which
      means this will be the second time scsi_abort_command() has been called for
      the same command.  IE the first abort went out, did its thing, but now the
      same command has timed out again.
      
      So this flag gets cleared, and scsi_abort_command() returns FAILED, and _no_
      asynchronous abort is being scheduled.  scsi_times_out() will then proceed to
      call scsi_eh_scmd_add().  But as we've cleared the SCSI_EH_ABORT_SCHEDULED
      flag the SCSI_EH_CANCEL_CMD flag will continue to be set, and the command will
      be aborted with the main SCSI EH routine.
      Reported-by: NAlan Stern <stern@rowland.harvard.edu>
      Tested-by: NAndreas Reis <andreas.reis@gmail.com>
      Signed-off-by: NHannes Reinecke <hare@suse.de>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      7daf4804
    • A
      [SCSI] Fix command result state propagation · 644373a4
      Alan Stern 提交于
      We're seeing a case where the contents of scmd->result isn't being reset after
      a SCSI command encounters an error, is resubmitted, times out and then gets
      handled.  The error handler acts on the stale result of the previous error
      instead of the timeout.  Fix this by properly zeroing the scmd->status before
      the command is resubmitted.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      644373a4
    • J
      [SCSI] Fix spurious request sense in error handling · d555a2ab
      James Bottomley 提交于
      We unconditionally execute scsi_eh_get_sense() to make sure all failed
      commands that should have sense attached, do.  However, the routine forgets
      that some commands, because of the way they fail, will not have any sense code
      ... we should not bother them with a REQUEST_SENSE command.  Fix this by
      testing to see if we actually got a CHECK_CONDITION return and skip asking for
      sense if we don't.
      Tested-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      d555a2ab