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

efi: Make 'efi_enabled' a function to query EFI facilities

2013-02-04T00:27:05+00:00

commit 83e68189745ad931c2afd45d8ee3303929233e7f upstream.

Originally 'efi_enabled' indicated whether a kernel was booted from
EFI firmware. Over time its semantics have changed, and it now
indicates whether or not we are booted on an EFI machine with
bit-native firmware, e.g. 64-bit kernel with 64-bit firmware.

The immediate motivation for this patch is the bug report at,

    https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557

which details how running a platform driver on an EFI machine that is
designed to run under BIOS can cause the machine to become
bricked. Also, the following report,

    https://bugzilla.kernel.org/show_bug.cgi?id=47121

details how running said driver can also cause Machine Check
Exceptions. Drivers need a new means of detecting whether they're
running on an EFI machine, as sadly the expression,

    if (!efi_enabled)

hasn't been a sufficient condition for quite some time.

Users actually want to query 'efi_enabled' for different reasons -
what they really want access to is the list of available EFI
facilities.

For instance, the x86 reboot code needs to know whether it can invoke
the ResetSystem() function provided by the EFI runtime services, while
the ACPI OSL code wants to know whether the EFI config tables were
mapped successfully. There are also checks in some of the platform
driver code to simply see if they're running on an EFI machine (which
would make it a bad idea to do BIOS-y things).

This patch is a prereq for the samsung-laptop fix patch.

Signed-off-by: Matt Fleming 
Cc: David Airlie 
Cc: Corentin Chary 
Cc: Matthew Garrett 
Cc: Dave Jiang 
Cc: Olof Johansson 
Cc: Peter Jones 
Cc: Colin Ian King 
Cc: Steve Langasek 
Cc: Tony Luck 
Cc: Konrad Rzeszutek Wilk 
Cc: Rafael J. Wysocki 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

SCSI: sd: Reshuffle init_sd to avoid crash

2013-01-28T04:49:01+00:00

commit afd5e34b2bb34881d3a789e62486814a49b47faa upstream.

scsi_register_driver will register a prep_fn() function, which
in turn migh need to use the sd_cdp_pool for DIF.
Which hasn't been initialised at this point, leading to
a crash. So reshuffle the init_sd() and exit_sd() paths
to have the driver registered last.

Signed-off-by: Joel D. Diaz 
Signed-off-by: Hannes Reinecke 
Signed-off-by: James Bottomley 
Cc: CAI Qian 
Signed-off-by: Greg Kroah-Hartman

qla2xxx: Look up LUN for abort requests

2013-01-17T16:45:57+00:00

commit 06e97b489006f28e23bb028febfa1c01c266d676 upstream.

Search through the list of pending commands on the session list to find
the command the initiator is actually aborting, so that we can pass the
correct LUN to the core TMR handling code.

(nab: Allow abort requests to work to LUN=0 with mainline target code)

Signed-off-by: Steve Hodgson 
Signed-off-by: Roland Dreier 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman

SCSI: qla2xxx: Free rsp_data even on error in qla2x00_process_loopback()

2013-01-17T16:45:57+00:00

commit 9bceab4e08c5e329e9def7fe1cab41c467236517 upstream.

Signed-off-by: Steve Hodgson 
Signed-off-by: Armen Baloyan 
Signed-off-by: Saurav Kashyap 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: qla2xxx: Change in setting UNLOADING flag and FC vports logout sequence while unloading qla2xxx driver.

2013-01-17T16:45:56+00:00

commit 220d36b4c2d96446e88d561714829ec5801b4fc7 upstream.

Signed-off-by: Giridhar Malavali 
Signed-off-by: Saurav Kashyap 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: qla2xxx: Test and clear FCPORT_UPDATE_NEEDED atomically.

2013-01-17T16:45:56+00:00

commit a394aac88506159e047630fc90dc2242568382d8 upstream.

When the qla2xxx driver loses access to multiple, remote ports, there is a race
condition which can occur which will keep the request stuck on a scsi request
queue indefinitely.

This bad state occurred do to a race condition with how the FCPORT_UPDATE_NEEDED
bit is set in qla2x00_schedule_rport_del(), and how it is cleared in
qla2x00_do_dpc().  The problem port has its drport pointer set, but it has never
been processed by the driver to inform the fc transport that the port has been
lost.  qla2x00_schedule_rport_del() sets drport, and then sets the
FCPORT_UPDATE_NEEDED bit.  In qla2x00_do_dpc(), the port lists are walked and
any drport pointer is handled and the fc transport informed of the port loss,
then the FCPORT_UPDATE_NEEDED bit is cleared.  This leaves a race where the
dpc thread is processing one port removal, another port removal is marked
with a call to qla2x00_schedule_rport_del(), and the dpc thread clears the
bit for both removals, even though only the first removal was actually
handled.  Until another event occurs to set FCPORT_UPDATE_NEEDED, the later
port removal is never finished and qla2xxx stays in a bad state which causes
requests to become stuck on request queues.

This patch updates the driver to test and clear FCPORT_UPDATE_NEEDED
atomically.  This ensures the port state changes are processed and not lost.

Signed-off-by: David Jeffery 
Signed-off-by: Chad Dupuis 
Signed-off-by: Saurav Kashyap 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: qla2xxx: Properly set result field of bsg_job reply structure for success and failure.

2013-01-17T16:45:56+00:00

commit 63ea923a97cb0d78efcbbd229950e101588f0ddb upstream.

FC transport on receiving bsg_job submission failure, calls bsg_job->job_done()
and sets the bsg_job->reply->result the returned value. In contrast, when the
success code (0) is returned fc transport doesn't call bsg_job->job_done() and
doesn't populate bsg_job->reply->result.

Signed-off-by: Steve Hodgson 
Signed-off-by: Armen Baloyan 
Signed-off-by: Saurav Kashyap 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: prevent stack buffer overflow in host_reset

2013-01-17T16:45:56+00:00

commit 072f19b4bea31cdd482d79f805413f2f9ac9e233 upstream.

store_host_reset() has tried to re-invent the wheel to compare sysfs strings.
Unfortunately it did so poorly and never bothered to check the input from
userspace before overwriting stack with it, so something simple as:

echo "WoopsieWoopsie" >
/sys/devices/pseudo_0/adapter0/host0/scsi_host/host0/host_reset

would result in:

[  316.310101] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff81f5bac7
[  316.310101]
[  316.320051] Pid: 6655, comm: sh Tainted: G        W    3.7.0-rc5-next-20121114-sasha-00016-g5c9d68d-dirty #129
[  316.320051] Call Trace:
[  316.340058] pps pps0: PPS event at 1352918752.620355751
[  316.340062] pps pps0: capture assert seq #303
[  316.320051]  [] panic+0xcd/0x1f4
[  316.320051]  [] ? store_host_reset+0xd7/0x100
[  316.320051]  [] __stack_chk_fail+0x16/0x20
[  316.320051]  [] store_host_reset+0xd7/0x100
[  316.320051]  [] dev_attr_store+0x13/0x30
[  316.320051]  [] sysfs_write_file+0x101/0x170
[  316.320051]  [] vfs_write+0xb8/0x180
[  316.320051]  [] sys_write+0x50/0xa0
[  316.320051]  [] tracesys+0xe1/0xe6

Fix this by uninventing whatever was going on there and just use sysfs_streq.

Bug introduced by 29443691 ("[SCSI] scsi: Added support for adapter and
firmware reset").

[jejb: added necessary const to prevent compile warnings]
Signed-off-by: Sasha Levin 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: mvsas: fix undefined bit shift

2013-01-17T16:45:56+00:00

commit beecadea1b8d67f591b13f7099559f32f3fd601d upstream.

The macro bit(n) is defined as ((u32)1 << n), and thus it doesn't work
with n >= 32, such as in mvs_94xx_assign_reg_set():

	if (i >= 32) {
		mvi->sata_reg_set |= bit(i);
		...
	}

The shift ((u32)1 << n) with n >= 32 also leads to undefined behavior.
The result varies depending on the architecture.

This patch changes bit(n) to do a 64-bit shift.  It also simplifies
mv_ffc64() using __ffs64(), since invoking ffz() with ~0 is undefined.

Signed-off-by: Xi Wang 
Acked-by: Xiangliang Yu 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

megaraid: fix BUG_ON() from incorrect use of delayed work

2012-12-04T15:29:47+00:00

megaraid use INIT_WORK to declare a hotplug_work, but cast the
hotplug_work from work_struct to delayed_work and
schedule_delayed_work on it.  This is very dangerous, as other part of
delayed_work might be kernel memories allocated by others.

With commit 8852aac ("workqueue: mod_delayed_work_on() shouldn't queue
timer on 0 delay"), schedule_delayed_work() will check dwork->timer
before queue_work even when @delay is 0, this causes megaraid code to
hit the BUG_ON() in workqueue code.  Change megaraid code to use
delayed work.

Signed-off-by: Xiaotian Feng 
Signed-off-by: Tejun Heo 
Cc: Neela Syam Kolli 
Cc: "James E.J. Bottomley" 
Cc: linux-scsi@vger.kernel.org