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

sym53c8xx_2: Set DID_REQUEUE return code when aborting squeue

2014-07-09T18:14:03+00:00

commit fd1232b214af43a973443aec6a2808f16ee5bf70 upstream.

This patch fixes I/O errors with the sym53c8xx_2 driver when the disk
returns QUEUE FULL status.

When the controller encounters an error (including QUEUE FULL or BUSY
status), it aborts all not yet submitted requests in the function
sym_dequeue_from_squeue.

This function aborts them with DID_SOFT_ERROR.

If the disk has full tag queue, the request that caused the overflow is
aborted with QUEUE FULL status (and the scsi midlayer properly retries
it until it is accepted by the disk), but the sym53c8xx_2 driver aborts
the following requests with DID_SOFT_ERROR --- for them, the midlayer
does just a few retries and then signals the error up to sd.

The result is that disk returning QUEUE FULL causes request failures.

The error was reproduced on 53c895 with COMPAQ BD03685A24 disk
(rebranded ST336607LC) with command queue 48 or 64 tags.  The disk has
64 tags, but under some access patterns it return QUEUE FULL when there
are less than 64 pending tags.  The SCSI specification allows returning
QUEUE FULL anytime and it is up to the host to retry.

Signed-off-by: Mikulas Patocka 
Cc: Matthew Wilcox 
Cc: James Bottomley 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

virtio-scsi: fix various bad behavior on aborted requests

2014-07-09T18:13:59+00:00

commit 8faeb529b2dabb9df691d614dda18910a43d05c9 upstream.

Even though the virtio-scsi spec guarantees that all requests related
to the TMF will have been completed by the time the TMF itself completes,
the request queue's callback might not have run yet.  This causes requests
to be completed more than once, and as a result triggers a variety of
BUGs or oopses.

Signed-off-by: Paolo Bonzini 
Reviewed-by: Venkatesh Srinivas 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Greg Kroah-Hartman

virtio-scsi: avoid cancelling uninitialized work items

2014-07-09T18:13:59+00:00

commit cdda0e5acbb78f7b777049f8c27899e5c5bb368f upstream.

Calling the workqueue interface on uninitialized work items isn't a
good idea even if they're zeroed. It's not failing catastrophically only
through happy accidents.

Signed-off-by: Paolo Bonzini 
Reviewed-by: Stefan Hajnoczi 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Greg Kroah-Hartman

ibmvscsi: Add memory barriers for send / receive

2014-07-09T18:13:59+00:00

commit 7114aae02742d6b5c5a0d39a41deb61d415d3717 upstream.

Add a memory barrier prior to sending a new command to the VIOS
to ensure the VIOS does not receive stale data in the command buffer.
Also add a memory barrier when processing the CRQ for completed commands.

Signed-off-by: Brian King 
Acked-by: Nathan Fontenot 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Greg Kroah-Hartman

ibmvscsi: Abort init sequence during error recovery

2014-07-09T18:13:59+00:00

commit 9ee755974bea2f9880e517ec985dc9dede1b3a36 upstream.

If a CRQ reset is triggered for some reason while in the middle
of performing VSCSI adapter initialization, we don't want to
call the done function for the initialization MAD commands as
this will only result in two threads attempting initialization
at the same time, resulting in failures.

Signed-off-by: Brian King 
Acked-by: Nathan Fontenot 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Greg Kroah-Hartman

net: Use netlink_ns_capable to verify the permisions of netlink messages

2014-06-26T19:12:37+00:00

[ Upstream commit 90f62cf30a78721641e08737bda787552428061e ]

It is possible by passing a netlink socket to a more privileged
executable and then to fool that executable into writing to the socket
data that happens to be valid netlink message to do something that
privileged executable did not intend to do.

To keep this from happening replace bare capable and ns_capable calls
with netlink_capable, netlink_net_calls and netlink_ns_capable calls.
Which act the same as the previous calls except they verify that the
opener of the socket had the desired permissions as well.

Reported-by: Andy Lutomirski 
Signed-off-by: "Eric W. Biederman" 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

SCSI: megaraid: Use resource_size_t for PCI resources, not long

2014-06-16T20:42:53+00:00

commit 11f8a7b31f2140b0dc164bb484281235ffbe51d3 upstream.

The assumption that sizeof(long) >= sizeof(resource_size_t) can lead to
truncation of the PCI resource address, meaning this driver didn't work
on 32-bit systems with 64-bit PCI adressing ranges.

Signed-off-by: Ben Collins 
Acked-by: Sumit Saxena 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: megaraid: missing bounds check in mimd_to_kioc()

2014-05-31T04:52:11+00:00

commit 3de2260140417759c669d391613d583baf03b0cf upstream.

pthru32->dataxferlen comes from the user so we need to check that it's
not too large so we don't overflow the buffer.

Reported-by: Nico Golde 
Reported-by: Fabian Yamaguchi 
Signed-off-by: Dan Carpenter 
Acked-by: Sumit Saxena 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: dual scan thread bug fix

2014-05-31T04:52:11+00:00

commit f2495e228fce9f9cec84367547813cbb0d6db15a upstream.

In the highly unusual case where two threads are running concurrently through
the scanning code scanning the same target, we run into the situation where
one may allocate the target while the other is still using it.  In this case,
because the reap checks for STARGET_CREATED and kills the target without
reference counting, the second thread will do the wrong thing on reap.

Fix this by reference counting even creates and doing the STARGET_CREATED
check in the final put.

Tested-by: Sarah Sharp 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

scsi: fix our current target reap infrastructure

2014-05-31T04:52:11+00:00

commit e63ed0d7a98014fdfc2cfeb3f6dada313dcabb59 upstream.

This patch eliminates the reap_ref and replaces it with a proper kref.
On last put of this kref, the target is removed from visibility in
sysfs.  The final call to scsi_target_reap() for the device is done from
__scsi_remove_device() and only if the device was made visible.  This
ensures that the target disappears as soon as the last device is gone
rather than waiting until final release of the device (which is often
too long).

Reviewed-by: Alan Stern 
Tested-by: Sarah Sharp 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman