We were running i/o and performing a bunch of hba resets in a loop.
This forces a lot of target removes and then rescans. Since the
resets are occuring during scan it's causing the scan i/o to timeout,
invoking error recovery, etc.  We end up getting some nasty crashing
in scsi_scan.c due to references to old sdevs that are failing
but had some lingering references that kept them around.

Fix by setting device state to SDEV_DEL if the LLD's slave_alloc
fails.
Signed-off-by: NJames Smart <james.smart@emulex.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

This patch makes part of the scsi probe (which is mostly device spin up and the
partition scan) asynchronous. Only the part that runs after getting the device
number allocated is asynchronous, ensuring that device numbering remains stable.
Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>

[jejb: limit ioctl to returning 20 characters to avoid overrun
       on long device names and add a few more conversions]
Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

This patch changes scsi_probe_lun() to retry INQUIRY if the device has
not actually sent back any INQUIRY data,

This enables the Thecus N2050 storage device to work better. The
firmware on that device starts up strangely; it sends no data in
response to the initial INQUIRY, and it sends the INQUIRY information
in response to the followup REQUEST SENSE. But after that it works
better, so retrying the INQUIRY is enough to get it going.
Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

scsi_execute() and scsi_execute_req() discard the residual length
information. Some callers need it. This adds residual argument
(optional) to scsi_execute and scsi_execute_req.
Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

SCSI-ml manages the queueing limits for the device and host, but
does not do so at the target level. However something something similar
can come in userful when a driver is transitioning a transport object to
the the blocked state, becuase at that time we do not want to queue
io and we do not want the queuecommand to be called again.

The patch adds code similar to the exisiting SCSI_ML_*BUSY handlers.
You can now return SCSI_MLQUEUE_TARGET_BUSY when we hit
a transport level queueing issue like the hw cannot allocate some
resource at the iscsi session/connection level, or the target has temporarily
closed or shrunk the queueing window, or if we are transitioning
to the blocked state.

bnx2i, when they rework their firmware according to netdev
developers requests, will also need to be able to limit queueing at this
level. bnx2i will hook into libiscsi, but will allocate a scsi host per
netdevice/hba, so unlike pure software iscsi/iser which is allocating
a host per session, it cannot set the scsi_host->can_queue and return
SCSI_MLQUEUE_HOST_BUSY to reflect queueing limits on the transport.

The iscsi class/driver can also set a scsi_target->can_queue value which
reflects the max commands the driver/class can support. For iscsi this
reflects the number of commands we can support for each session due to
session/connection hw limits, driver limits, and to also reflect the
session/targets's queueing window.

Changes:
v1 - initial patch.
v2 - Fix scsi_run_queue handling of multiple blocked targets.
Previously we would break from the main loop if a device was added back on
the starved list. We now run over the list and check if any target is
blocked.
v3 - Rediff for scsi-misc.
Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

Brian King <brking@linux.vnet.ibm.com> reported that fibre channel
devices can oops during scanning if their ports block (because the
device goes from CREATED -> BLOCK -> RUNNING rather than CREATED ->
BLOCK -> CREATED).

Fix this by adding a new state: CREATED_BLOCK which can only transition
back to CREATED and disallow the CREATED -> BLOCK transition.  Now both
the created and blocked states that the mid-layer recognises can include
CREATED_BLOCK.
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

The created and blocked states are very shortly going to correspond to
mixed sdev_state states.
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

For IBM z series certain LUNs can no longer be accessed.

This is because kernel version 2.6.19 a check was introduced not to
create a generic SCSI device for devices that return PQ=1 and
PDT=0x1f. For WLUNs (see SAM-3, p. 41ff) generic SCSI devices should
be created unconditionally without looking at the PQ bit, so add a
check for WLUNs in with this test.
Acked-by: NMartin Petermann <martin@linux.vnet.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

[jejb: fixed up a ton of missed conversions.

 All of you are on notice this has happened, driver trees will now
 need to be rebased]
Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
Cc: SCSI List <linux-scsi@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

The mutex is released on a successful return, so it would seem that it
should be released on an error return as well.

The semantic patch that makes this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)

// <smpl>
@@
expression l;
@@

mutex_lock(l);
... when != mutex_unlock(l)
    when any
    when strict
(
if (...) { ... when != mutex_unlock(l)
+   mutex_unlock(l);
    return ...;
}
|
mutex_unlock(l);
)
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

Make the needlessly global struct scsi_{host,target}_type static.
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

Some drivers have duplicated unlikely() macros.  IS_ERR() already has
unlikely() in itself.

This patch cleans up such pointless code.
Signed-off-by: NHirofumi Nakagawa <hnakagawa@miraclelinux.com>
Acked-by: NDavid S. Miller <davem@davemloft.net>
Acked-by: NJeff Garzik <jeff@garzik.org>
Cc: Paul Clements <paul.clements@steeleye.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: David Brownell <david-b@pacbell.net>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Michael Halcrow <mhalcrow@us.ibm.com>
Cc: Anton Altaparmakov <aia21@cantab.net>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Carsten Otte <cotte@de.ibm.com>
Cc: Patrick McHardy <kaber@trash.net>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.de>
Acked-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The current target allocation code registeres each possible target
with sysfs; it will be deleted again if no useable LUN on this target
was found. This results in a string of 'target add/target remove' uevents.

Based on a patch by Hannes Reinecke <hare@suse.de> this patch reworks
the target allocation code so that only uevents for existing targets
are sent. The sysfs registration is split off from the existing
scsi_target_alloc() into a in a new scsi_add_target() function, which
should be called whenever an existing target is found. Only then a
uevent is sent, so we'll be generating events for existing targets
only.
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

This patch implements scsi_host and scsi_target device types
and adds both to the scsi_bus.
Signed-off-by: NHannes Reinecke <hare@suse.de>
Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

Fix docbook problem in SCSI source files.
These cause the generated docbook to be incorrect.
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

Fix docbook problem in SCSI source files.
These cause the generated docbook to be incorrect.
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

While trying to convert the SPI transport class to attribute groups, I
discovered that we don't actually have any transport configure points
for either the target or the host.  This patch adds these missing
transport class triggers.  The host one is simply done after the add,
the target one tries to be more clever and add it after devices may have
been placed on the target (so the device configure will have set up the
target parameters).
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

Some SCSI tape medium changers that need the BLIST_SINGLELUN flag have
the medium changer at one LUN and the tape drive at a different LUN.
The inquiry string of the tape drive may be different from that of the
medium changer.  In order for single_lun to be effective, every
scsi_device under a given scsi_target must have it set.  This means that
there needs to be a blacklist entry for BOTH the medium changer AND the
tape drive, which is impractical because some medium changers may be
paired with a variety of different tape drive models.  It makes more
sense to put the single_lun flag in scsi_target instead of scsi_device,
which causes every device at a given target ID to inherit the single_lun
flag from one LUN.  This makes it possible to blacklist just the medium
changer and not the tape drive.
Signed-off-by: NTony Battersby <tonyb@cybernetics.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

Add Documentation/DocBook/scsi_midlayer.tmpl, add to Makefile, and update
lots of kerneldoc comments in drivers/scsi/*.

Updated with comments from Stefan Richter, Stephen M. Cameron,
 James Bottomley and Randy Dunlap.
Signed-off-by: NRob Landley <rob@landley.net>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

Originally based on a patch by Kristen Carlson Accardi @ Intel.
Copious input from James Bottomley.
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

If kthread_run failed, we would fail to scan the host, and leak the
allocated async_scan_data.  Since using a separate thread is just an
optimisation, do the scan synchronously if we fail to spawn a thread.
Signed-off-by: NMatthew Wilcox <matthew@wil.cx>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

In scsi module I've found some inconsistency between variable type
used in module_param_named and type passed to module_param_named as an
argument. Especially the inconsistency of `max_scsi_luns' parameter is
a bit serious because the description text says "last scsi LUN (should
be between 1 and 2^32-1)".
Signed-off-by: NMasatake YAMATO <jet@gyve.org>
Acked-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Stress-testing and some thought has revealed some places where
asynchronous scanning needs some more attention to locking.

 - Since async_scan is a bit, we need to hold the host_lock while
   modifying it to prevent races against other CPUs modifying the word
   that bit is in.  This is probably a theoretical race for the moment,
   but other patches may change that.
 - The async_scan bit means not only that this host is being scanned
   asynchronously, but that all the devices attached to this host are not
   yet added to sysfs.  So we must ensure that this bit is always in sync.
   I've chosen to do this with the scan_mutex since it's already acquired
   in most of the right places.
 - If the host changes state to deleted while we're in the middle of
   a scan, we'll end up with some devices on the host's list which must
   be deleted.  Add a check to scsi_sysfs_add_devices() to ensure the
   host is still running.
 - To avoid the async_scan bit being protected by three locks, the
   async_scan_lock now only protects the scanning_list.
Signed-off-by: NMatthew Wilcox <matthew@wil.cx>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

This patch tidies up scsi_add_lun a bit.  I rewrote the kerneldoc to match
the actual parameters, moved the check for RBC and MMC REPORT_LUN devices
away from the switch(), changed the setup of sdev->type to account for
BLIST_ISROM, moved the check for BLIST_NO_ULD_ATTACH further down in
the function, removed a bogus comment and fixed some whitespace issues.
Signed-off-by: NMatthew Wilcox <matthew@wil.cx>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

When reporting SCSI devices to the SCSI midlayer, use the FCP LUN as
LUN reported to the SCSI layer. With this approach, zfcp does not have
to create unique LUNS, and this code can be removed.
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NSwen Schillig <swen@vnet.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

CONFIG_MODULES=y
CONFIG_SCSI=y
CONFIG_SCSI_SCAN_ASYNC=y
CONFIG_SCSI_WAIT_SCAN=m

2.6.21-rc5-mm2 VFS panics unable to find my root on /dev/sda2, but boots
okay if I change drivers/scsi/Kconfig to "default y" instead of "default m"
for SCSI_WAIT_SCAN.

Make sure there's a late_initcall to scsi_complete_async_scans when it's
built in, so a monolithic SCSI_SCAN_ASYNC kernel can rely on the scans
being completed before trying to mount root, even if they're slow.

[akpm@linux-foundation.org: build fixes]
Signed-off-by: NHugh Dickins <hugh@veritas.com>
Acked-by: NMatthew Wilcox <matthew@wil.cx>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

The #ifdef MODULE around the export of scsi_complete_async_scans()
which is the API the scsi_wait_scan module uses is incorrect and
causes the symbol to be undefined in certain circumstances leading to
a build failure.  Remove the defines.
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Globally, s/driverfs/sysfs/g.
Signed-off-by: NRobert P. J. Day <rpjday@mindspring.com>
Signed-off-by: NAdrian Bunk <bunk@stusta.de>

This patch will affect the CDB in INQUIRY commands sent to LUNs above 0 
when LUN-0 reports a scsi_level of 0; the LUN bits will no longer be set 
in the second byte of the CDB.  This is as it should be.  Nevertheless, 
it's possible that some wacky device might be adversely affected.  I doubt 
anyone will complain...
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

A particular USB device has been reporting short inquiry lengths.  The
SCSI code cannot operate properly unless we get an inquiry length of
36 or above (because of the way we parse vendor and product), so
assume at least 36 bytes are valid even if the device reports fewer.
This is wrong, but it's no worse than what we're doing now (using the
garbage beyond the last reported valid byte).
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

I had thought that all drivers which didn't call scsi_scan_host()
called scsi_scan_target().  Some, such as sbp2, mptsas and libata-scsi,
call scsi_add_device() or __scsi_add_device().  We just need to wait
for the currently executing async scans to complete first.  This is the
same code that's in scsi_scan_target(), except that we have to return
an error instead of void when we're declining to scan at all.
Signed-off-by: NMatthew Wilcox <matthew@wil.cx>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Hi,

Minor typo ...
In my first iteration of patches (that got merged), the
BLIST_ATTACH_PQ3 actually had the value 0x800000, but that
got changed later to avoid conflicts. This piece must have
been overlooked.
You could obviously do something like %x and then add the
bitflags, but that looks overkill for something that does
not tend to change.

Please merge.
(Patch applied against latest 2.6.20rc version that I tested.)

From: Kurt Garloff <kurt@garloff.de>
Subject: [SCSI SCAN] Fix logging message for PQ3 devices

The blacklist flags BLIST_ATTACH_PQ3 has value 0x1000000,
not 0x800000.
Signed-off-by: NKurt Garloff <garloff@suse.de>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Apparently no ATAPI CD/DVD actually supports REPORT LUNS (in spite of
claiming scsi-3 compliance, where it's mandatory) and worse, some
crash or flake out on being sent the command.  This may actually be
due to a conflict between SPC and MMC with MMC not listing REPORT LUNS
as mandatory.  The same standards conflict exists for RBC as well.

Fix all of this by reversing the blacklists for CDROM and RBC devices
(i.e. now they have to have the BLIST_REPORTLUNS2 flag set even if the
inquiry data returns scsi-3 compliance).
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

If either scsi_complete_async_scans() is called a second time
before the first call has finished, or a host scan is started while
scsi_complete_async_scans() is still sleeping, it would fail to wake up
the other task, which would sleep forever.

I've changed the kernel-doc to make it clear that
scsi_complete_async_scans() only guarantees that scans which started
before it was called are guaranteed to have finished when it returns.
I considered making it wait until all scans are completed, but it can't
guarantee that no more scans will start before it returns anyway, and it
runs the risk of confusing other callers of scsi_complete_async_scans()
for hosts actually scanning.
Signed-off-by: NMatthew Wilcox <matthew@wil.cx>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

If a driver can find its own targets, it can now fill in scan_finished and
(optionally) scan_start in the scsi_host_template.  Then, when it calls
scsi_scan_host(), it will be called back (from a thread if asynchronous
discovery is enabled), first to start the scan, and then at intervals to
check if the scan is completed.

Also make scsi_prep_async_scan and scsi_finish_async_scan static.
Signed-off-by: NMatthew Wilcox <matthew@wil.cx>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Drivers that called scsi_scan_target() instead of scsi_scan_host() were
still adding devices; this needs to be under the control of userspace,
not the driver.
Signed-off-by: NMatthew Wilcox <matthew@wil.cx>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Without this patch, the user has to add a kernel command line parameter
to get asynchronous SCSI scanning.  Now they can select the default at
compile time and still override it at boot time if they need to.
Signed-off-by: NMatthew Wilcox <matthew@wil.cx>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Pass the work_struct pointer to the work function rather than context data.
The work function can use container_of() to work out the data.

For the cases where the container of the work_struct may go away the moment the
pending bit is cleared, it is made possible to defer the release of the
structure by deferring the clearing of the pending bit.

To make this work, an extra flag is introduced into the management side of the
work_struct.  This governs auto-release of the structure upon execution.

Ordinarily, the work queue executor would release the work_struct for further
scheduling or deallocation by clearing the pending bit prior to jumping to the
work function.  This means that, unless the driver makes some guarantee itself
that the work_struct won't go away, the work function may not access anything
else in the work_struct or its container lest they be deallocated..  This is a
problem if the auxiliary data is taken away (as done by the last patch).

However, if the pending bit is *not* cleared before jumping to the work
function, then the work function *may* access the work_struct and its container
with no problems.  But then the work function must itself release the
work_struct by calling work_release().

In most cases, automatic release is fine, so this is the default.  Special
initiators exist for the non-auto-release case (ending in _NAR).
Signed-Off-By: NDavid Howells <dhowells@redhat.com>

This patch (as810c) copies a minimum of 36 bytes of INQUIRY data, even if
the device claims that not all of them are valid.  Often badly behaved
devices put plausible data in the Vendor, Product, and Revision strings but
set the Additional Length byte to a small value.  Using potentially valid
data is certainly better than allocating a short buffer and then reading
beyond the end of it, which is what we do now.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: James Bottomley <James.Bottomley@steeleye.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>