linux/drivers/block, branch v3.8

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc

2013-02-15T20:05:57Z

Pull sparc fixes from David Miller: "A couple small fixes for sparc including some THP brown-paper-bag material: 1) During the merging of all the THP support for various architectures, sparc missed adding a HAVE_ARCH_TRANSPARENT_HUGEPAGE to it's Kconfig, oops. 2) Sparc needs to be mindful of hugepages in get_user_pages_fast(). 3) Fix memory leak in SBUS probe, from Cong Ding. 4) The sunvdc virtual disk client driver has a test of the bitmask of vdisk server supported operations which was off by one bit" * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc: sunvdc: Fix off-by-one in generic_request(). sparc64: Fix get_user_pages_fast() wrt. THP. sparc64: Add missing HAVE_ARCH_TRANSPARENT_HUGEPAGE. sparc: kernel/sbus.c: fix memory leakage

sunvdc: Fix off-by-one in generic_request().

2013-02-14T19:49:01Z

The 'operations' bitmap corresponds one-for-one with the operation codes, no adjustment is necessary. Reported-by: Mark Kettenis Signed-off-by: David S. Miller

Merge branch 'for-linus' of git://git.kernel.dk/linux-block

2013-02-06T21:38:33Z

Pull block layer updates from Jens Axboe: "I've got a few bits pending for 3.8 final, that I better get sent out. It's all been sitting for a while, I consider it safe. It contains: - Two bug fixes for mtip32xx, fixing a driver hang and a crash. - A few-liner protocol error fix for drbd. - A few fixes for the xen block front/back driver, fixing a potential data corruption issue. - A race fix for disk_clear_events(), causing spurious warnings. Out of the Chrome OS base. - A deadlock fix for disk_clear_events(), moving it to the a unfreezable workqueue. Also from the Chrome OS base." * 'for-linus' of git://git.kernel.dk/linux-block: drbd: fix potential protocol error and resulting disconnect/reconnect mtip32xx: fix for crash when the device surprise removed during rebuild mtip32xx: fix for driver hang after a command timeout block: prevent race/cleanup block: remove deadlock in disk_clear_events xen-blkfront: handle bvecs with partial data llist/xen-blkfront: implement safe version of llist_for_each_entry xen-blkback: implement safe iterator for the list of persistent grants

Merge branch 'for-jens' of git://git.drbd.org/linux-drbd into for-linus

2013-01-22T15:22:11Z

drbd: fix potential protocol error and resulting disconnect/reconnect

2013-01-21T21:58:36Z

When we notice a disk failure on the receiving side, we stop sending it new incoming writes. Depending on exact timing of various events, the same transfer log epoch could end up containing both replicated (before we noticed the failure) and local-only requests (after we noticed the failure). The sanity checks in tl_release(), called when receiving a P_BARRIER_ACK, check that the ack'ed transfer log epoch matches the expected epoch, and the number of contained writes matches the number of ack'ed writes. In this case, they counted both replicated and local-only writes, but the peer only acknowledges those it has seen. We get a mismatch, resulting in a protocol error and disconnect/reconnect cycle. Messages logged are "BAD! BarrierAck #%u received with n_writes=%u, expected n_writes=%u!\n" A similar issue can also be triggered when starting a resync while having a healthy replication link, by invalidating one side, forcing a full sync, or attaching to a diskless node. Fix this by closing the current epoch if the state changes in a way that would cause the replication intent of the next write. Epochs now contain either only non-replicated, or only replicated writes. Signed-off-by: Philipp Reisner Signed-off-by: Lars Ellenberg

Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux

2013-01-21T00:44:28Z

Pull module fixes and a virtio block fix from Rusty Russell: "Various minor fixes, but a slightly more complex one to fix the per-cpu overload problem introduced recently by kvm id changes." * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux: module: put modules in list much earlier. module: add new state MODULE_STATE_UNFORMED. module: prevent warning when finit_module a 0 sized file virtio-blk: Don't free ida when disk is in use

mtip32xx: fix for crash when the device surprise removed during rebuild

2013-01-11T13:35:58Z

When rebuild is in progress, disk->queue is yet to be created. Surprise removing the device will call remove()-> del_gendisk(). del_gendisk() expect disk->queue be not NULL. Fix is to call put_disk() when disk_queue is NULL. Signed-off-by: Asai Thambi S P Signed-off-by: Jens Axboe

mtip32xx: fix for driver hang after a command timeout

2013-01-11T13:35:55Z

If an I/O command times out when a PIO command is active, MTIP_PF_EH_ACTIVE_BIT is not cleared. This results in I/O hang in the driver. Fix is to clear this bit. Signed-off-by: Asai Thambi S P Signed-off-by: Jens Axboe

Drivers: block: remove __dev* attributes.

2013-01-03T23:57:15Z

CONFIG_HOTPLUG is going away as an option. As a result, the __dev* markings need to be removed. This change removes the use of __devinit, __devexit_p, __devinitdata, __devinitconst, and __devexit from these drivers. Based on patches originally written by Bill Pemberton, but redone by me in order to handle some of the coding style issues better, by hand. Cc: Bill Pemberton Cc: Mike Miller Cc: Chirag Kantharia Cc: Geoff Levand Cc: Jim Paris Cc: Rusty Russell Cc: "Michael S. Tsirkin" Cc: Grant Likely Cc: Matthew Wilcox Cc: Keith Busch Cc: "David S. Miller" Cc: Benjamin Herrenschmidt Cc: NeilBrown Cc: Jens Axboe Cc: Tao Guo Signed-off-by: Greg Kroah-Hartman

virtio-blk: Don't free ida when disk is in use

2013-01-02T05:07:58Z

When a file system is mounted on a virtio-blk disk, we then remove it and then reattach it, the reattached disk gets the same disk name and ids as the hot removed one. This leads to very nasty effects - mostly rendering the newly attached device completely unusable. Trying what happens when I do the same thing with a USB device, I saw that the sd node simply doesn't get free'd when a device gets forcefully removed. Imitate the same behavior for vd devices. This way broken vd devices simply are never free'd and newly attached ones keep working just fine. Signed-off-by: Alexander Graf Signed-off-by: Rusty Russell Cc: stable@kernel.org