27 Jan, 2006

1 commit

  • 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: Brian King
    Signed-off-by: James Bottomley

    brking@us.ibm.com
     

15 Jan, 2006

1 commit

  • LLDDs should never see REQ_BLOCK_PC requests, we can handle them just
    fine in the core code. There is a small behaviour change in that some
    check in sr's rw_intr are bypassed, but I consider the old behaviour
    a bug.

    Mike found this cleanup opportunity and provdided early patches, so all
    the credit goes to him, even if I redid the patches from scratch beause
    that was easier than forward-porting the old patches.

    Signed-off-by: Christoph Hellwig
    Signed-off-by: James Bottomley

    Christoph Hellwig
     

09 Jan, 2006

1 commit


06 Jan, 2006

3 commits

  • Signed-off-by: Jens Axboe

    Jens Axboe
     
  • All ordered request related stuff delegated to HLD. Midlayer
    now doens't deal with ordered setting or prepare_flush
    callback. sd.c updated to deal with blk_queue_ordered
    setting. Currently, ordered tag isn't used as SCSI midlayer
    cannot guarantee request ordering.

    Signed-off-by: Tejun Heo
    Signed-off-by: Jens Axboe

    Tejun Heo
     
  • add @uptodate argument to end_that_request_last() and @error
    to rq_end_io_fn(). there's no generic way to pass error code
    to request completion function, making generic error handling
    of non-fs request difficult (rq->errors is driver-specific and
    each driver uses it differently). this patch adds @uptodate
    to end_that_request_last() and @error to rq_end_io_fn().

    for fs requests, this doesn't really matter, so just using the
    same uptodate argument used in the last call to
    end_that_request_first() should suffice. imho, this can also
    help the generic command-carrying request jens is working on.

    Signed-off-by: tejun heo
    Signed-Off-By: Jens Axboe

    Tejun Heo
     

16 Dec, 2005

2 commits

  • I forgot to do a git-update-cache on the merged files ...

    James Bottomley
     
  • - 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: Mike Christie
    Signed-off-by: James Bottomley

    Mike Christie
     

15 Dec, 2005

4 commits

  • Add kmemcache of scsi io contexts.

    In the future when we finalize on where these functions will live
    we can add a mempool for it and do a bioset for out REQ_BLOCK_PC
    bios. This is needed becuase the dm-multipath handlers will
    want to use the scsi_exectute* functions for failover and we cannot
    have them and the bio device allocating from the same mempool.

    Signed-off-by: Mike Christie
    Signed-off-by: James Bottomley

    Mike Christie
     
  • sd does not allow scsi_io_completion to retry commands for
    SG_IO requests, and it make sense that it should not happen for st
    SG_IO commands too. If for st we hit the bottom of scsi_io_completion
    we will probably screw things up pretty bad. This patch returns to the
    block layer that the whole command completed and relies on the caller to check
    the request errors field. For initialization commands like in sd, this adds
    the previous behavior where scsi_io_completion did not process the error.

    Signed-off-by: Mike Christie
    Signed-off-by: James Bottomley

    Mike Christie
     
  • For tape we need to control the retries. This patch adds a retries
    counter on the request for REQ_BLOCK_PC commands originating from
    scsi_execute* to use. REQ_BLOCK_PC commands comming from the block
    layer SG_IO path continue to use the retires set in the ULD init_command.
    (scsi_execute* does not set the gendisk so we do not execute
    the init_command in that path).

    Signed-off-by: Mike Christie
    Signed-off-by: James Bottomley

    Mike Christie
     
  • Add scsi helpers to create really-large-requests and convert
    scsi-ml to scsi_execute_async().

    Per Jens's previous comments, I placed this function in scsi_lib.c.
    I made it follow all the queue's limits - I think I did at least :), so
    I removed the warning on the function header.

    I think the scsi_execute_* functions should eventually take a request_queue
    and be placed some place where the dm-multipath hw_handler can use them
    if that failover code is going to stay in the kernel. That conversion
    patch will be sent in another mail though.

    Signed-off-by: Mike Christie
    Signed-off-by: James Bottomley

    Mike Christie
     

14 Dec, 2005

1 commit


13 Dec, 2005

1 commit

  • This reverts commit 1b0997f561bf46689cc6e0903f342e9bf2506bf1, which in
    turn reverted 34ea80ec6a02ad02e6b9c75c478c18e5880d6713 (which is thus
    re-instated).

    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: Linus Torvalds

    Linus Torvalds
     

03 Dec, 2005

1 commit


09 Nov, 2005

1 commit

  • 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: James Bottomley

    goggin, edward
     

07 Nov, 2005

1 commit


29 Oct, 2005

2 commits


28 Oct, 2005

1 commit


17 Oct, 2005

1 commit

  • 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: Alan Stern
    Signed-off-by: James Bottomley

    Alan Stern
     

19 Sep, 2005

1 commit


18 Sep, 2005

1 commit

  • I found one other thing that needs to be fixed. The call to
    scsi_release_buffers in scsi_unprep_request causes an oops, because the
    sgtable has already been freed in scsi_io_completion. The following patch
    is needed.

    Signed-off-by: Alan Stern
    Signed-off-by: James Bottomley

    Alan Stern
     

15 Sep, 2005

2 commits

  • 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: James Bottomley

    James Bottomley
     
  • 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: Timothy Thelin
    Signed-off-by: James Bottomley

    Timothy Thelin
     

11 Sep, 2005

1 commit


10 Sep, 2005

1 commit

  • 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: James Bottomley

    James Bottomley
     

09 Sep, 2005

2 commits

  • From: Alan Stern

    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: Alan Stern

    Rejections fixed up and
    Signed-off-by: James Bottomley

    James Bottomley
     
  • 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
    scsi_issue_flush_fn.
    This calls sd_issue_flush which calls sd_sync_cache, which calls
    scsi_execute_request.
    This will (as sshdr != NULL) call
    kmalloc(SCSI_SENSE_BUFFERSIZE, GFP_KERNEL)

    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
    message.

    Signed-off-by: Neil Brown
    Signed-off-by: James Bottomley

    Neil Brown
     

07 Sep, 2005

1 commit

  • 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: James Bottomley

    James Bottomley
     

29 Aug, 2005

6 commits


28 Aug, 2005

3 commits


31 Jul, 2005

1 commit