linux-stable.git/drivers/block, branch v3.4.22

NVMe: Fix uninitialized iod compiler warning

2012-12-03T19:46:36+00:00

commit c7d36ab8fa04c213328119a9c0d66985fe204ee5 upstream.

Signed-off-by: Keith Busch 
Signed-off-by: Matthew Wilcox 
Signed-off-by: Greg Kroah-Hartman

rbd: Fix ceph_snap_context size calculation

2012-11-26T19:38:10+00:00

(cherry picked from commit f9f9a1904467816452fc70740165030e84c2c659)

ceph_snap_context->snaps is an u64 array

Signed-off-by: Zheng Yan 
Reviewed-by: Alex Elder 
Signed-off-by: Greg Kroah-Hartman

rbd: store snapshot id instead of index

2012-11-26T19:38:10+00:00

(cherry picked from commit 77dfe99fe3cb0b2b0545e19e2d57b7a9134ee3c0)

When a device was open at a snapshot, and snapshots were deleted or
added, data from the wrong snapshot could be read. Instead of
assuming the snap context is constant, store the actual snap id when
the device is initialized, and rely on the OSDs to signal an error
if we try reading from a snapshot that was deleted.

Signed-off-by: Josh Durgin 
Reviewed-by: Alex Elder 
Reviewed-by: Yehuda Sadeh 
Signed-off-by: Greg Kroah-Hartman

rbd: protect read of snapshot sequence number

2012-11-26T19:38:10+00:00

(cherry picked from commit 403f24d3d51760a8b9368d595fa5f48c309f1a0f)

This is updated whenever a snapshot is added or deleted, and the
snapc pointer is changed with every refresh of the header.

Signed-off-by: Josh Durgin 
Reviewed-by: Alex Elder 
Reviewed-by: Yehuda Sadeh 
Signed-off-by: Greg Kroah-Hartman

rbd: don't hold spinlock during messenger flush

2012-11-26T19:38:10+00:00

(cherry picked from commit cd9d9f5df6098c50726200d4185e9e8da32785b3)

A recent change made changes to the rbd_client_list be protected by
a spinlock.  Unfortunately in rbd_put_client(), the lock is taken
before possibly dropping the last reference to an rbd_client, and on
the last reference that eventually calls flush_workqueue() which can
sleep.

The problem was flagged by a debug spinlock warning:
    BUG: spinlock wrong CPU on CPU#3, rbd/27814

The solution is to move the spinlock acquisition and release inside
rbd_client_release(), which is the spot where it's really needed for
protecting the removal of the rbd_client from the client list.

Signed-off-by: Alex Elder 
Reviewed-by: Sage Weil 
Signed-off-by: Greg Kroah-Hartman

floppy: do put_disk on current dr if blk_init_queue fails

2012-11-05T08:50:41+00:00

commit 238ab78469c6ab7845b43d5061cd3c92331b2452 upstream.

If blk_init_queue fails, we do not call put_disk on the current dr
(dr is decremented first in the error handling loop).

Reviewed-by: Ben Hutchings 
Signed-off-by: Herton Ronaldo Krzesinski 
Signed-off-by: Jiri Kosina 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

aoe: assert AoE packets marked as requiring no checksum

2012-10-12T20:38:46+00:00

[ Upstream commit 8babe8cc6570ed896b7b596337eb8fe730c3ff45 ]

In order for the network layer to see that AoE requires
no checksumming in a generic way, the packets must be
marked as requiring no checksum, so we make this requirement
explicit with the assertion.

Signed-off-by: Ed Cashin 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

xen/m2p: do not reuse kmap_op->dev_bus_addr

2012-10-02T17:30:06+00:00

commit 2fc136eecd0c647a6b13fcd00d0c41a1a28f35a5 upstream.

If the caller passes a valid kmap_op to m2p_add_override, we use
kmap_op->dev_bus_addr to store the original mfn, but dev_bus_addr is
part of the interface with Xen and if we are batching the hypercalls it
might not have been written by the hypervisor yet. That means that later
on Xen will write to it and we'll think that the original mfn is
actually what Xen has written to it.

Rather than "stealing" struct members from kmap_op, keep using
page->index to store the original mfn and add another parameter to
m2p_remove_override to get the corresponding kmap_op instead.
It is now responsibility of the caller to keep track of which kmap_op
corresponds to a particular page in the m2p_override (gntdev, the only
user of this interface that passes a valid kmap_op, is already doing that).

Reported-and-Tested-By: Sander Eikelenboom 
Signed-off-by: Stefano Stabellini 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman

nbd: clear waiting_queue on shutdown

2012-10-02T17:29:59+00:00

commit fded4e090c60100d709318896c79816d68d5b47d upstream.

Fix a serious but uncommon bug in nbd which occurs when there is heavy
I/O going to the nbd device while, at the same time, a failure (server,
network) or manual disconnect of the nbd connection occurs.

There is a small window between the time that the nbd_thread is stopped
and the socket is shutdown where requests can continue to be queued to
nbd's internal waiting_queue.  When this happens, those requests are
never completed or freed.

The fix is to clear the waiting_queue on shutdown of the nbd device, in
the same way that the nbd request queue (queue_head) is already being
cleared.

Signed-off-by: Paul Clements 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

cciss: fix handling of protocol error

2012-10-02T17:29:50+00:00

commit 2453f5f992717251cfadab6184fbb3ec2f2e8b40 upstream.

If a command completes with a status of CMD_PROTOCOL_ERR, this
information should be conveyed to the SCSI mid layer, not dropped
on the floor.  Unlike a similar bug in the hpsa driver, this bug
only affects tape drives and CD and DVD ROM drives in the cciss
driver, and to induce it, you have to disconnect (or damage) a
cable, so it is not a very likely scenario (which would explain
why the bug has gone undetected for the last 10 years.)

Signed-off-by: Stephen M. Cameron 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman