1. 20 1月, 2015 1 次提交
  2. 09 1月, 2015 1 次提交
  3. 15 12月, 2014 1 次提交
  4. 25 11月, 2014 3 次提交
  5. 12 11月, 2014 7 次提交
  6. 30 10月, 2014 1 次提交
    • J
      blk-mq: add a 'list' parameter to ->queue_rq() · 74c45052
      Jens Axboe 提交于
      Since we have the notion of a 'last' request in a chain, we can use
      this to have the hardware optimize the issuing of requests. Add
      a list_head parameter to queue_rq that the driver can use to
      temporarily store hw commands for issue when 'last' is true. If we
      are doing a chain of requests, pass in a NULL list for the first
      request to force issue of that immediately, then batch the remainder
      for deferred issue until the last request has been sent.
      
      Instead of adding yet another argument to the hot ->queue_rq path,
      encapsulate the passed arguments in a blk_mq_queue_data structure.
      This is passed as a constant, and has been tested as faster than
      passing 4 (or even 3) args through ->queue_rq. Update drivers for
      the new ->queue_rq() prototype. There are no functional changes
      in this patch for drivers - if they don't use the passed in list,
      then they will just queue requests individually like before.
      Signed-off-by: NJens Axboe <axboe@fb.com>
      74c45052
  7. 28 10月, 2014 1 次提交
  8. 23 9月, 2014 5 次提交
  9. 19 9月, 2014 1 次提交
  10. 16 9月, 2014 1 次提交
  11. 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
  12. 23 8月, 2014 1 次提交
  13. 20 8月, 2014 1 次提交
    • G
      scsi: Fix qemu boot hang problem · 480cadc2
      Guenter Roeck 提交于
      The latest kernel fails to boot qemu arm images when using scsi
      for disk access. Boot gets stuck after the following messages.
      
      brd: module loaded
      sym53c8xx 0000:00:0c.0: enabling device (0100 -> 0103)
      sym0: <895a> rev 0x0 at pci 0000:00:0c.0 irq 93
      sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking
      sym0: SCSI BUS has been reset.
      scsi host0: sym-2.2.3
      
      Bisect points to commit 71e75c97 ("scsi: convert device_busy to
      atomic_t"). Code inspection shows the following suspicious change
      in scsi_request_fn.
      
      out_delay:
      -       if (sdev->device_busy == 0 && !scsi_device_blocked(sdev))
      +       if (atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
      		blk_delay_queue(q, SCSI_QUEUE_DELAY);
      	}
      
      'sdev->device_busy == 0' was replaced with 'atomic_read(&sdev->device_busy)',
      meaning the logic was reversed. Changing this expression to
      '!atomic_read(&sdev->device_busy)' fixes the problem.
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Reviewed-by: NHannes Reinecke <hare@suse.de>
      Acked-by: NJens Axboe <axboe@fb.com>
      Reviewed-by: NVenkatesh Srinivas <venkateshs@google.com>
      Reviewed-by: NWebb Scales <webbnh@hp.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      480cadc2
  14. 16 8月, 2014 1 次提交
    • G
      [SCSI] fix qemu boot hang problem · 045065d8
      Guenter Roeck 提交于
      The latest kernel fails to boot qemu arm images when using scsi
      for disk access. Boot gets stuck after the following messages.
      
      brd: module loaded
      sym53c8xx 0000:00:0c.0: enabling device (0100 -> 0103)
      sym0: <895a> rev 0x0 at pci 0000:00:0c.0 irq 93
      sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking
      sym0: SCSI BUS has been reset.
      scsi host0: sym-2.2.3
      
      Bisect points to commit 71e75c97 ("scsi: convert device_busy to
      atomic_t"). Code inspection shows the following suspicious change
      in scsi_request_fn.
      
      out_delay:
      -       if (sdev->device_busy == 0 && !scsi_device_blocked(sdev))
      +       if (atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
      		blk_delay_queue(q, SCSI_QUEUE_DELAY);
      	}
      
      'sdev->device_busy == 0' was replaced with 'atomic_read(&sdev->device_busy)',
      meaning the logic was reversed. Changing this expression to
      '!atomic_read(&sdev->device_busy)' fixes the problem.
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Reviewed-by: NHannes Reinecke <hare@suse.de>
      Acked-by: NJens Axboe <axboe@fb.com>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Fixes: 71e75c97Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      045065d8
  15. 26 7月, 2014 5 次提交
  16. 25 7月, 2014 8 次提交
  17. 18 7月, 2014 1 次提交