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

SCSI: libsas: fix taskfile corruption in sas_ata_qc_fill_rtf

2012-07-16T16:04:37+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 
Signed-off-by: Greg Kroah-Hartman

SCSI & usb-storage: add try_rc_10_first flag

2012-07-16T16:04:10+00:00

commit 6a0bdffa0073857870a4ed1b4489762146359eb4 upstream.

Several bug reports have been received recently for USB mass-storage
devices that don't handle READ CAPACITY(16) commands properly.  They
report bogus sizes, in some cases becoming unusable as a result.

The bugs were triggered by commit
09b6b51b0b6c1b9bb61815baf205e4d74c89ff04 (SCSI & usb-storage: add
flags for VPD pages and REPORT LUNS), which caused usb-storage to stop
overriding the SCSI level reported by devices.  By default, the sd
driver will try READ CAPACITY(16) first for any device whose level is
above SCSI_SPC_2.

It seems likely that any device large enough to require the use of
READ CAPACITY(16) (i.e., 2 TB or more) would be able to handle READ
CAPACITY(10) commands properly.  Indeed, I don't know of any devices
that don't handle READ CAPACITY(10) properly.

Therefore this patch (as1559) adds a new flag telling the sd driver
to try READ CAPACITY(10) before READ CAPACITY(16), and sets this flag
for every USB mass-storage device.  If a device really is larger than
2 TB, sd will fall back to READ CAPACITY(16) just as it used to.

This fixes Bugzilla #43391.

Signed-off-by: Alan Stern 
Acked-by: Hans de Goede 
CC: "James E.J. Bottomley" 
CC: Matthew Dharm 
Signed-off-by: Greg Kroah-Hartman

SCSI: mpt2sas: Fix unsafe using smp_processor_id() in preemptible

2012-06-22T18:36:55+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: Greg Kroah-Hartman

SCSI: Fix dm-multipath starvation when scsi host is busy

2012-06-09T15:36:06+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: Greg Kroah-Hartman

SCSI: fix scsi_wait_scan

2012-06-09T15:36:05+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: Greg Kroah-Hartman

isci: fix oem parameter validation on single controller skus

2012-06-01T07:18:15+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

Reported-by: Dave Jiang 
Tested-by: Dave Jiang 
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman

SCSI: mpt2sas: Fix for panic happening because of improper memory allocation

2012-06-01T07:18:15+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: Greg Kroah-Hartman

[SCSI] virtio_scsi: fix TMF use-after-free

2012-05-10T07:27:06+00:00

Fix a use-after-free in the TMF path, where cmd may have been already
freed by virtscsi_complete_free when wait_for_completion restarts
executing virtscsi_tmf.  Technically a race, but in practice the command
will always be freed long before the completion waiter is awoken.

The fix is to make callers specifying a completion responsible for
freeing the command in all cases.

Signed-off-by: Hu Tao 
Signed-off-by: Paolo Bonzini 
Signed-off-by: James Bottomley

[SCSI] fix oops in all legacy host adapters caused by 6f381fa

2012-05-10T07:24:13+00:00

Commit 6f381fa344911d5a234b13574433cf23036f9467
Author: Lin Ming 

[SCSI] scsi_lib: use correct DMA device in __scsi_alloc_queue
 
Caused a regression where we oops in every legacy mode SCSI host driver
because they supply a NULL pointer to scsi_add_host().  Fix this by checking
for the NULL in scsi_add_host_with_dma() and changing the DMA device to being
the platform_bus in that case (which replicates the original behaviour).

Reported-by: Al Viro 
Signed-off-by: James Bottomley

[SCSI] qla2xxx: Update version number to 8.04.00.03-k.

2012-05-10T07:19:10+00:00

Signed-off-by: Giridhar Malavali 
Signed-off-by: Chad Dupuis 
Signed-off-by: James Bottomley