Граф коммитов

14 Коммитов

Автор SHA1 Сообщение Дата
Christoph Hellwig 3af6b35261 scsi: remove scsi_driver owner field
The driver core driver structure has grown an owner field and now
requires it to be set for all modular drivers.  Set it up for
all scsi_driver instances and get rid of the now superflous
scsi_driver owner field.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reported-by: Shane M Seymour <shane.seymour@hp.com>
Reviewed-by: Ewan D. Milne <emilne@redhat.com
Reviewed-by: Hannes Reinecke <hare@suse.de>
2014-11-24 20:01:28 +01:00
Christoph Hellwig 4f1e576575 scsi: mark scsi_setup_blk_pc_cmnd static
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
2014-07-17 22:16:29 +02:00
Christoph Hellwig 3868cf8ea7 scsi: restructure command initialization for TYPE_FS requests
We should call the device handler prep_fn for all TYPE_FS requests,
not just simple read/write calls that are handled by the disk driver.

Restructure the common I/O code to call the prep_fn handler and zero
out the CDB, and just leave the call to scsi_init_io to the ULDs.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
2014-07-17 22:11:27 +02:00
Christoph Hellwig a1b73fc194 scsi: reintroduce scsi_driver.init_command
Instead of letting the ULD play games with the prep_fn move back to
the model of a central prep_fn with a callback to the ULD.  This
already cleans up and shortens the code by itself, and will be required
to properly support blk-mq in the SCSI midlayer.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Nicholas Bellinger <nab@linux-iscsi.org>
Reviewed-by: Mike Christie <michaelc@cs.wisc.edu>
Reviewed-by: Hannes Reinecke <hare@suse.de>
2014-05-19 12:35:09 +02:00
James Bottomley 2451079bc2 [SCSI] Fix erratic device offline during EH
Commit 18a4d0a22e
(Handle disk devices which can not process medium access commands)
was introduced to offline any device which cannot process medium
access commands.
However, commit 3eef6257de
(Reduce error recovery time by reducing use of TURs) reduced
the number of TURs by sending it only on the first failing
command, which might or might not be a medium access command.
So in combination this results in an erratic device offlining
during EH; if the command where the TUR was sent upon happens
to be a medium access command the device will be set offline,
if not everything proceeds as normal.

This patch moves the check to the final test, eliminating
this problem.

Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2013-12-19 07:39:02 -08:00
Martin K. Petersen 18a4d0a22e [SCSI] Handle disk devices which can not process medium access commands
We have experienced several devices which fail in a fashion we do not
currently handle gracefully in SCSI. After a failure these devices will
respond to the SCSI primary command set (INQUIRY, TEST UNIT READY, etc.)
but any command accessing the storage medium will time out.

The following patch adds an callback that can be used by upper level
drivers to inspect the results of an error handling command. This in
turn has been used to implement additional checking in the SCSI disk
driver.

If a medium access command fails twice but TEST UNIT READY succeeds both
times in the subsequent error handling we will offline the device. The
maximum number of failed commands required to take a device offline can
be tweaked in sysfs.

Also add a new error flag to scsi_debug which allows this scenario to be
easily reproduced.

[jejb: fix up integer parsing to use kstrtouint]
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2012-02-19 10:14:52 -06:00
Hannes Reinecke b391277a56 sd, sr: fix Driver 'sd' needs updating message
If a SCSI ULD driver sets blk_queue_prep_rq(), it should clean it
up itself on remove(), and not from the bus callbacks. This
removes the need to hook into bus->remove(), which should not
be used at the same time as driver->remove().

[jejb: fix sdkp initialisation problem due to mismerge]
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
2009-06-21 12:01:27 -05:00
Linus Torvalds 7b3d9545f9 Revert "scsi: revert "[SCSI] Get rid of scsi_cmnd->done""
This reverts commit ac40532ef0, which gets
us back the original cleanup of 6f5391c283.

It turns out that the bug that was triggered by that commit was
apparently not actually triggered by that commit at all, and just the
testing conditions had changed enough to make it appear to be due to it.

The real problem seems to have been found by Peter Osterlund:

  "pktcdvd sets it [block device size] when opening the /dev/pktcdvd
   device, but when the drive is later opened as /dev/scd0, there is
   nothing that sets it back.  (Btw, 40944 is possible if the disk is a
   CDRW that was formatted with "cdrwtool -m 10236".)

   The problem is that pktcdvd opens the cd device in non-blocking mode
   when pktsetup is run, and doesn't close it again until pktsetup -d is
   run.  The effect is that if you meanwhile open the cd device,
   blkdev.c:do_open() doesn't call bd_set_size() because
   bdev->bd_openers is non-zero."

In particular, to repeat the bug (regardless of whether commit
6f5391c283 is applied or not):

  " 1. Start with an empty drive.
    2. pktsetup 0 /dev/scd0
    3. Insert a CD containing an isofs filesystem.
    4. mount /dev/pktcdvd/0 /mnt/tmp
    5. umount /mnt/tmp
    6. Press the eject button.
    7. Insert a DVD containing a non-writable filesystem.
    8. mount /dev/scd0 /mnt/tmp
    9. find /mnt/tmp -type f -print0 | xargs -0 sha1sum >/dev/null
    10. If the DVD contains data beyond the physical size of a CD, you
        get I/O errors in the terminal, and dmesg reports lots of
        "attempt to access beyond end of device" errors."

which in turn is because the nested open after the media change won't
cause the size to be set properly (because the original open still holds
the block device, and we only do the bd_set_size() when we don't have
other people holding the device open).

The proper fix for that is probably to just do something like

	bdev->bd_inode->i_size = (loff_t)get_capacity(disk)<<9;

in fs/block_dev.c:do_open() even for the cases where we're not the
original opener (but *not* call bd_set_size(), since that will also
change the block size of the device).

Cc: Peter Osterlund <petero2@telia.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Matthew Wilcox <matthew@wil.cx>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-06 10:17:12 -08:00
Ingo Molnar ac40532ef0 scsi: revert "[SCSI] Get rid of scsi_cmnd->done"
This reverts commit 6f5391c283 ("[SCSI]
Get rid of scsi_cmnd->done") that was supposed to be a cleanup commit,
but apparently it causes regressions:

  Bug 9370 - v2.6.24-rc2-409-g9418d5d: attempt to access beyond end of device
  http://bugzilla.kernel.org/show_bug.cgi?id=9370

this patch should be reintroduced in a more split-up form to make
testing of it easier.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Acked-by: Matthew Wilcox <matthew@wil.cx>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-02 13:11:06 -08:00
Matthew Wilcox 6f5391c283 [SCSI] Get rid of scsi_cmnd->done
The ULD ->done callback moves into the scsi_driver.  By moving the call
to scsi_io_completion() from scsi_blk_pc_done() to scsi_finish_command(),
we can eliminate the latter entirely.  By returning 'good_bytes' from
the ->done callback (rather than invoking scsi_io_completion()), we can
stop exporting scsi_io_completion().

Also move the prototypes from sd.h to sd.c as they're all internal anyway.
Rename sd_rw_intr to sd_done and rw_intr to sr_done.

Inspired-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2007-10-12 14:52:46 -04:00
James Bottomley 7f9a6bc4e9 [SCSI] move ULD attachment into the prep function
One of the intents of the block prep function was to allow ULDs to use
it for preprocessing.  The original SCSI model was to have a single prep
function and add a pointer indirect filter to build the necessary
commands.  This patch reverses that, does away with the init_command
field of the scsi_driver structure and makes ULDs attach directly to the
prep function instead.  The value is really that it allows us to begin
to separate the ULDs from the SCSI mid layer (as long as they don't use
any core functions---which is hard at the moment---a ULD doesn't even
need SCSI to bind).

Acked-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2007-10-12 14:49:30 -04:00
James Bottomley 03a5743a12 [SCSI] sd: disentangle barriers in SCSI
Our current implementation has a generic set of barrier functions that
go through the SCSI driver model.  Realistically, this is unnecessary,
because the only device that can use barriers (sd) can set the flush
functions up at probe or revalidate time.  This patch pulls the barrier
functions out of the mid layer and scsi driver model and relocates them
directly in sd.

Acked-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2007-08-04 08:37:04 -05:00
Tejun Heo 461d4e90c8 [BLOCK] update SCSI to use new blk_ordered for barriers
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 <htejun@gmail.com>
Signed-off-by: Jens Axboe <axboe@suse.de>
2006-01-06 09:52:55 +01:00
Linus Torvalds 1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00