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

SCSI: Avoid dangling pointer in scsi_requeue_command()

2012-08-09T15:27:34+00:00

commit 940f5d47e2f2e1fa00443921a0abf4822335b54d upstream.

When we call scsi_unprep_request() the command associated with the request
gets destroyed and therefore drops its reference on the device.  If this was
the only reference, the device may get released and we end up with a NULL
pointer deref when we call blk_requeue_request.

Reported-by: Mike Christie 
Signed-off-by: Bart Van Assche 
Reviewed-by: Mike Christie 
Reviewed-by: Tejun Heo 
[jejb: enhance commend and add commit log for stable]
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: fix hot unplug vs async scan race

2012-08-09T15:27:34+00:00

commit 3b661a92e869ebe2358de8f4b3230ad84f7fce51 upstream.

The following crash results from cases where the end_device has been
removed before scsi_sysfs_add_sdev has had a chance to run.

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000098
 IP: [] sysfs_create_dir+0x32/0xb6
 ...
 Call Trace:
  [] kobject_add_internal+0x120/0x1e3
  [] ? trace_hardirqs_on+0xd/0xf
  [] kobject_add_varg+0x41/0x50
  [] kobject_add+0x64/0x66
  [] device_add+0x12d/0x63a
  [] ? _raw_spin_unlock_irqrestore+0x47/0x56
  [] ? module_refcount+0x89/0xa0
  [] scsi_sysfs_add_sdev+0x4e/0x28a
  [] do_scan_async+0x9c/0x145

...teach scsi_sysfs_add_devices() to check for deleted devices() before
trying to add them, and teach scsi_remove_target() how to remove targets
that have not been added via device_add().

Reported-by: Dariusz Majchrzak 
Signed-off-by: Dan Williams 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: fix eh wakeup (scsi_schedule_eh vs scsi_restart_operations)

2012-08-09T15:27:34+00:00

commit 57fc2e335fd3c2f898ee73570dc81426c28dc7b4 upstream.

Rapid ata hotplug on a libsas controller results in cases where libsas
is waiting indefinitely on eh to perform an ata probe.

A race exists between scsi_schedule_eh() and scsi_restart_operations()
in the case when scsi_restart_operations() issues i/o to other devices
in the sas domain.  When this happens the host state transitions from
SHOST_RECOVERY (set by scsi_schedule_eh) back to SHOST_RUNNING and
->host_busy is non-zero so we put the eh thread to sleep even though
->host_eh_scheduled is active.

Before putting the error handler to sleep we need to check if the
host_state needs to return to SHOST_RECOVERY for another trip through
eh.  Since i/o that is released by scsi_restart_operations has been
blocked for at least one eh cycle, this implementation allows those
i/o's to run before another eh cycle starts to discourage hung task
timeouts.

Reported-by: Tom Jackson 
Tested-by: Tom Jackson 
Signed-off-by: Dan Williams 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: libsas: fix sas_discover_devices return code handling

2012-08-09T15:27:34+00:00

commit b17caa174a7e1fd2e17b26e210d4ee91c4c28b37 upstream.

commit 198439e4 [SCSI] libsas: do not set res = 0 in sas_ex_discover_dev()
commit 19252de6 [SCSI] libsas: fix wide port hotplug issues

The above commits seem to have confused the return value of
sas_ex_discover_dev which is non-zero on failure and
sas_ex_join_wide_port which just indicates short circuiting discovery on
already established ports.  The result is random discovery failures
depending on configuration.

Calls to sas_ex_join_wide_port are the source of the trouble as its
return value is errantly assigned to 'res'.  Convert it to bool and stop
returning its result up the stack.

Tested-by: Dan Melnic 
Reported-by: Dan Melnic 
Signed-off-by: Dan Williams 
Reviewed-by: Jack Wang 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: libsas: continue revalidation

2012-08-09T15:27:34+00:00

commit 26f2f199ff150d8876b2641c41e60d1c92d2fb81 upstream.

Continue running revalidation until no more broadcast devices are
discovered.  Fixes cases where re-discovery completes too early in a
domain with multiple expanders with pending re-discovery events.
Servicing BCNs can get backed up behind error recovery.

Signed-off-by: Dan Williams 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

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

2012-06-09T15:32:57+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:32:57+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:13:00+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 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

SCSI: hpsa: Fix problem with MSA2xxx devices

2012-06-01T07:12:57+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 
Cc: Jonathan Nieder 
Signed-off-by: Greg Kroah-Hartman

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

2012-06-01T07:12:54+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