1. 26 Mar, 2006 1 commit
  2. 19 Mar, 2006 1 commit
  3. 27 Feb, 2006 4 commits
  4. 14 Feb, 2006 1 commit
    • James Bottomley's avatar
      [PATCH] add scsi_execute_in_process_context() API · faead26d
      James Bottomley authored
      We have several points in the SCSI stack (primarily for our device
      functions) where we need to guarantee process context, but (given the
      place where the last reference was released) we cannot guarantee this.
      This API gets around the issue by executing the function directly if
      the caller has process context, but scheduling a workqueue to execute
      in process context if the caller doesn't have it.  Unfortunately, it
      requires memory allocation in interrupt context, but it's better than
      what we have previously.  The true solution will require a bit of
      re-engineering, so isn't appropriate for 2.6.16.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
  5. 26 Jan, 2006 1 commit
    • brking@us.ibm.com's avatar
      [SCSI] Prevent scsi_execute_async from guessing cdb length · bb1d1073
      brking@us.ibm.com authored
      When the scsi_execute_async interface was added it ended up reducing
      the flexibility of userspace to send arbitrary scsi commands through
      sg using SG_IO. The SG_IO interface allows userspace to specify the
      CDB length. This is now ignored in scsi_execute_async and it is
      guessed using the COMMAND_SIZE macro, which is not always correct,
      particularly for vendor specific commands. This patch adds a cmd_len
      parameter to the scsi_execute_async interface to allow the caller
      to specify the length of the CDB.
      Signed-off-by: default avatarBrian King <brking@us.ibm.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
  6. 14 Jan, 2006 1 commit
  7. 09 Jan, 2006 1 commit
  8. 06 Jan, 2006 3 commits
  9. 15 Dec, 2005 2 commits
    • James Bottomley's avatar
      Fix up SCSI mismerge · 7b16318d
      James Bottomley authored
      I forgot to do a git-update-cache on the merged files ...
    • Mike Christie's avatar
      [SCSI] seperate max_sectors from max_hw_sectors · defd94b7
      Mike Christie authored
      - export __blk_put_request and blk_execute_rq_nowait
      needed for async REQ_BLOCK_PC requests
      - seperate max_hw_sectors and max_sectors for block/scsi_ioctl.c and
      SG_IO bio.c helpers per Jens's last comments. Since block/scsi_ioctl.c SG_IO was
      already testing against max_sectors and SCSI-ml was setting max_sectors and
      max_hw_sectors to the same value this does not change any scsi SG_IO behavior. It only
      prepares ll_rw_blk.c, scsi_ioctl.c and bio.c for when SCSI-ml begins to set
      a valid max_hw_sectors for all LLDs. Today if a LLD does not set it
      SCSI-ml sets it to a safe default and some LLDs set it to a artificial low
      value to overcome memory and feedback issues.
      Note: Since we now cap max_sectors to BLK_DEF_MAX_SECTORS, which is 1024,
      drivers that used to call blk_queue_max_sectors with a large value of
      max_sectors will now see the fs requests capped to BLK_DEF_MAX_SECTORS.
      Signed-off-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
  10. 14 Dec, 2005 4 commits
  11. 13 Dec, 2005 2 commits
  12. 12 Dec, 2005 1 commit
    • Linus Torvalds's avatar
      Revert revert of "[SCSI] fix usb storage oops" · 49d7bc64
      Linus Torvalds authored
      This reverts commit 1b0997f5, which in
      turn reverted 34ea80ec
       (which is thus
      Quoth James Bottomley:
        "All it's doing is deferring the device_put() from the
         scsi_put_command() to after the scsi_run_queue(), which doesn't fix
         the sleep while atomic problem of the device release method.  In both
         cases we still get the semaphore in atomic context problem which is
         caused by scsi_reap_target() doing a device_del(), which I assumed
         (wrongly) was valid from atomic context."
      who also promised to fix scsi_reap_target().
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  13. 09 Dec, 2005 1 commit
  14. 02 Dec, 2005 1 commit
  15. 08 Nov, 2005 1 commit
    • goggin, edward's avatar
      [SCSI] fix usb storage oops · 34ea80ec
      goggin, edward authored
      The problem is that scsi_run_queue is called from scsi_next_command()
      after doing a scsi_put_command.  If the command was the only thing
      holding the reference on the scsi_device then the resulting device put
      will tear down the block queue.  Fix this by taking a reference to the
      device and holding it around scsi_run_queue()
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
  16. 06 Nov, 2005 1 commit
  17. 28 Oct, 2005 3 commits
  18. 16 Oct, 2005 1 commit
    • Alan Stern's avatar
      [SCSI] Fix leak of Scsi_Cmnds · 7c72ce81
      Alan Stern authored
      When a request is deferred in scsi_init_io because the sg table could not
      be allocated, the associated scsi_cmnd is not released and the request is
      not marked with REQ_DONTPREP.  When the command is retried, if
      scsi_prep_fn decides to kill it then the scsi_cmnd will never be released.
      This patch (as573) changes scsi_init_io so that it calls scsi_put_command
      before deferring a request.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
  19. 19 Sep, 2005 1 commit
  20. 17 Sep, 2005 1 commit
  21. 14 Sep, 2005 2 commits
    • James Bottomley's avatar
      [SCSI] fix sym scsi boot hang · 59897dad
      James Bottomley authored
      On Wed, 2005-09-14 at 18:06 +1000, Anton Blanchard wrote:
      > And in particular it looks like the scsi_unprep_request in
      > scsi_queue_insert is causing it. The following patch fixes the boot
      > problems on the vscsi machine:
      OK, my fault.  Your fix is almost correct .. I was going to do this
      eventually, honest, because there's no need to unprep and reprep a
      command that comes in through scsi_queue_insert().
      However, I decided to leave it in to exercise the scsi_unprep_request()
      path just to make sure it was working.  What's happening, I think, is
      that we also use this path for retries.  Since we kill and reget the
      command each time, the retries decrement is never seen, so we're
      retrying forever.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
    • Timothy Thelin's avatar
      [SCSI] scsi: sd, sr, st, and scsi_lib all fail to copy cmd_len to new cmd · 186d330e
      Timothy Thelin authored
      This fixes an issue in scsi command initialization from a request
      where sd, sr, st, and scsi_lib all fail to copy the request's
      cmd_len to the scsi command's cmd_len field.
      Signed-off-by: default avatarTimothy Thelin <timothy.thelin@wdc.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
  22. 10 Sep, 2005 1 commit
  23. 09 Sep, 2005 3 commits
    • James Bottomley's avatar
      [SCSI] SCSI core: fix leakage of scsi_cmnd's · 788ce43a
      James Bottomley authored
      Actually, just one problem and one cosmetic fix:
      1) We need to dequeue for the loop and kill case (it seems easiest
      simply to dequeue in the scsi_kill_request() routine)
      2) There's no real need to drop the queue lock.  __scsi_done() is lock
      agnostic, so since there's no requirement, let's just leave it in to
      avoid any locking issues.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
    • James Bottomley's avatar
      [SCSI] SCSI core: fix leakage of scsi_cmnd's · e91442b6
      James Bottomley authored
      From: 	Alan Stern <stern@rowland.harvard.edu>
      This patch (as559b) adds a new routine, scsi_unprep_request, which
      gets called every place a request is requeued.  (That includes
      scsi_queue_insert as well as scsi_requeue_command.)  It also changes
      scsi_kill_requests to make it call __scsi_done with result equal to
      DID_NO_CONNECT << 16.  (I'm not sure if it's necessary to call
      scsi_init_cmd_errh here; maybe you can check on that.)  Finally, the
      patch changes the return value from scsi_end_request, to avoid
      returning a stale pointer in the case where the request was requeued.
      Fortunately the return value is used in only place, and the change
      actually simplified it.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Rejections fixed up and
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
    • Neil Brown's avatar
      [SCSI] fix possible deadlock in scsi_lib.c · 286f3e13
      Neil Brown authored
        If a filesystem, while writing out data, decides that it is good
      to issue a cache flush on a SCSI drive (or other 'sd' device), it will
      call blkdev_issue_flush which calls ->issue_flush_fn which is
      This calls sd_issue_flush which calls sd_sync_cache, which calls
      This will (as sshdr != NULL) call
      If memory is tight, the presence of GFP_KERNEL may cause write
      requests to be sent to some filesystem to free up memory, however if
      that filesystem is waiting for the issue_flush_fn to complete, you
      could get a deadlock.
      I wonder if it might be more appropriate to use GFP_NOIO as in the
      following patch.
      I wonder if it might be even more appropriate to cope better with a
      kmalloc failure, especially as in this use, sd_sync_cache only will
      use the sense information to print out a more informative error
      Signed-off-by: default avatarNeil Brown <neilb@suse.de>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
  24. 06 Sep, 2005 1 commit
    • James Bottomley's avatar
      [SCSI] quieten messages on scsi_execute commands · 3173d8c3
      James Bottomley authored
      scsi_io_completion() can be a bit noisy about certain conditions.
      Previously this wasn't a problem for internally generated commands,
      since they never hit it.  However, since we do all SCSI commands via
      bios, now they do.  user CD testers like magicdev are now getting not
      ready messages every time they touch the CD to see if there's anything
      in it.
      Fix this by making all scsi_execute commands REQ_QUIET and making
      scsi_finish_io() not say anything for REQ_QUIET.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
  25. 28 Aug, 2005 1 commit