linux-stable.git/drivers/scsi, branch v3.2.24

libsas: fix taskfile corruption in sas_ata_qc_fill_rtf

2012-07-25T03:11:12+00:00

commit 6ef1b512f4e6f936d89aa20be3d97a7ec7c290ac upstream.

fill_result_tf() grabs the taskfile flags from the originating qc which
sas_ata_qc_fill_rtf() promptly overwrites.  The presence of an
ata_taskfile in the sata_device makes it tempting to just copy the full
contents in sas_ata_qc_fill_rtf().  However, libata really only wants
the fis contents and expects the other portions of the taskfile to not
be touched by ->qc_fill_rtf.  To that end store a fis buffer in the
sata_device and use ata_tf_from_fis() like every other ->qc_fill_rtf()
implementation.

Reported-by: Praveen Murali 
Tested-by: Praveen Murali 
Signed-off-by: Dan Williams 
Signed-off-by: James Bottomley 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

mpt2sas: Fix unsafe using smp_processor_id() in preemptible

2012-06-19T22:18:14+00:00

commit a2c658505bf5c75516ee0a79287223e86a2474af upstream.

When CONFIG_DEBUG_PREEMPT is enabled, bug is observed in the smp_processor_id().
This is because smp_processor_id() is not called in preempt safe condition.

To fix this issue, use raw_smp_processor_id instead of smp_processor_id.

Signed-off-by: Nagalakshmi Nandigama 
Signed-off-by: James Bottomley 
Signed-off-by: Ben Hutchings

fix scsi_wait_scan

2012-06-10T13:41:47+00:00

commit 1ff2f40305772b159a91c19590ee159d3a504afc upstream.

Commit  c751085943362143f84346d274e0011419c84202
Author: Rafael J. Wysocki 
Date:   Sun Apr 12 20:06:56 2009 +0200

    PM/Hibernate: Wait for SCSI devices scan to complete during resume

Broke the scsi_wait_scan module in 2.6.30.  Apparently debian still uses it so
fix it and backport to stable before removing it in 3.6.

The breakage is caused because the function template in
include/scsi/scsi_scan.h is defined to be a nop unless SCSI is built in.
That means that in the modular case (which is every distro), the
scsi_wait_scan module does a simple async_synchronize_full() instead of
waiting for scans.

Signed-off-by: James Bottomley 
Signed-off-by: Ben Hutchings

Fix dm-multipath starvation when scsi host is busy

2012-06-10T13:41:34+00:00

commit b7e94a1686c5daef4f649f7f4f839cc294f07710 upstream.

block congestion control doesn't have any concept of fairness across
multiple queues.  This means that if SCSI reports the host as busy in
the queue congestion control it can result in an unfair starvation
situation in dm-mp if there are multiple multipath devices on the same
host.  For example:
http://www.redhat.com/archives/dm-devel/2012-May/msg00123.html

The fix for this is to report only the sdev busy state (and ignore the
host busy state) in the block congestion control call back.
The host is still congested, but the SCSI subsystem will sort out the
congestion in a fair way because it knows the relation between the
queues and the host.

[jejb: fixed up trailing whitespace]
Reported-by: Bernd Schubert 
Tested-by: Bernd Schubert 
Signed-off-by: Jun'ichi Nomura 
Signed-off-by: James Bottomley 
Signed-off-by: Ben Hutchings

hpsa: Add IRQF_SHARED back in for the non-MSI(X) interrupt handler

2012-05-30T23:43:53+00:00

commit 45bcf018d1a4779d592764ef57517c92589d55d7 upstream.

IRQF_SHARED is required for older controllers that don't support MSI(X)
and which may end up sharing an interrupt.  All the controllers hpsa
normally supports have MSI(X) capability, but older controllers may be
encountered via the hpsa_allow_any=1 module parameter.

Also remove deprecated IRQF_DISABLED.

Signed-off-by: Stephen M. Cameron 
Signed-off-by: James Bottomley 
Signed-off-by: Ben Hutchings

isci: fix oem parameter validation on single controller skus

2012-05-30T23:43:29+00:00

commit fc25f79af321c01a739150ba2c09435cf977a63d upstream.

OEM parameters [1] are parsed from the platform option-rom / efi
driver.  By default the driver was validating the parameters for the
dual-controller case, but in single-controller case only the first set
of parameters may be valid.

Limit the validation to the number of actual controllers detected
otherwise the driver may fail to parse the valid parameters leading to
driver-load or runtime failures.

[1] the platform specific set of phy address, configuration,and analog
    tuning values

[stable v3.0+]
Reported-by: Dave Jiang 
Tested-by: Dave Jiang 
Signed-off-by: Dan Williams 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

mpt2sas: Fix for panic happening because of improper memory allocation

2012-05-30T23:43:22+00:00

commit e42fafc25fa86c61824e8d4c5e7582316415d24f upstream.

The ioc->pfacts member in the IOC structure is getting set to zero
following a call to _base_get_ioc_facts due to the memset in that routine.
So if the ioc->pfacts was read after a host reset, there would be a NULL
pointer dereference. The routine _base_get_ioc_facts is called from context
of host reset.  The problem in _base_get_ioc_facts  is the size of
Mpi2IOCFactsReply is 64, whereas the sizeof "struct mpt2sas_facts" is 60,
so there is a four byte overflow resulting from the memset.

Also, there is memset in _base_get_port_facts using the incorrect structure,
it should be "struct mpt2sas_port_facts" instead of Mpi2PortFactsReply.

Signed-off-by: Nagalakshmi Nandigama 
Signed-off-by: James Bottomley 
Signed-off-by: Ben Hutchings

hpsa: Fix problem with MSA2xxx devices

2012-05-30T23:43:20+00:00

commit 9bc3711cbb67ac620bf09b4a147cbab45b2c36c0 upstream.

Upgraded firmware on Smart Array P7xx (and some others) made them show up as
SCSI revision 5 devices and this caused the driver to fail to map MSA2xxx
logical drives to the correct bus/target/lun.  A symptom of this would be that
the target ID of the logical drives as presented by the external storage array
is ignored, and all such logical drives are assigned to target zero,
differentiated only by LUN.  Some multipath software reportedly does not deal
well with this behavior, failing to recognize different paths to the same
device as such.

Signed-off-by: Stephen M. Cameron 
Signed-off-by: Scott Teel 
Signed-off-by: James Bottomley 
Signed-off-by: Ben Hutchings

libsas: fix false positive 'device attached' conditions

2012-05-11T12:14:47+00:00

commit 7d1d865181185bdf1316d236b1b4bd02c9020729 upstream.

Normalize phy->attached_sas_addr to return a zero-address in the case
when device-type == NO_DEVICE or the linkrate is invalid to handle
expanders that put non-zero sas addresses in the discovery response:

 sas: ex 5001b4da000f903f phy02:U:0 attached: 0100000000000000 (no device)
 sas: ex 5001b4da000f903f phy01:U:0 attached: 0100000000000000 (no device)
 sas: ex 5001b4da000f903f phy03:U:0 attached: 0100000000000000 (no device)
 sas: ex 5001b4da000f903f phy00:U:0 attached: 0100000000000000 (no device)

Reported-by: Andrzej Jakowski 
Signed-off-by: Dan Williams 
Signed-off-by: James Bottomley 
Signed-off-by: Ben Hutchings

libsas: fix sas_find_bcast_phy() in the presence of 'vacant' phys

2012-05-11T12:14:46+00:00

commit 1699490db339e2c6b3037ea8e7dcd6b2755b688e upstream.

If an expander reports 'PHY VACANT' for a phy index prior to the one
that generated a BCN libsas fails rediscovery.  Since a vacant phy is
defined as a valid phy index that will never have an attached device
just continue the search.

Signed-off-by: Thomas Jackson 
Signed-off-by: Dan Williams 
Signed-off-by: James Bottomley 
Signed-off-by: Ben Hutchings