--- /dev/null
+From b0239faaf87c38bb419c9264bf20817438ddc3a9 Mon Sep 17 00:00:00 2001
+From: Mike Snitzer <snitzer@redhat.com>
+Date: Tue, 3 Jul 2012 12:55:37 +0100
+Subject: dm persistent data: fix allocation failure in space map checker init
+
+From: Mike Snitzer <snitzer@redhat.com>
+
+commit b0239faaf87c38bb419c9264bf20817438ddc3a9 upstream.
+
+If CONFIG_DM_DEBUG_SPACE_MAPS is enabled and memory is fragmented and a
+sufficiently-large metadata device is used in a thin pool then the space
+map checker will fail to allocate the memory it requires.
+
+Switch from kmalloc to vmalloc to allow larger virtually contiguous
+allocations for the space map checker's internal count arrays.
+
+Reported-by: Vivek Goyal <vgoyal@redhat.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Alasdair G Kergon <agk@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/persistent-data/dm-space-map-checker.c | 30 +++++++++++++---------
+ 1 file changed, 19 insertions(+), 11 deletions(-)
+
+--- a/drivers/md/persistent-data/dm-space-map-checker.c
++++ b/drivers/md/persistent-data/dm-space-map-checker.c
+@@ -8,6 +8,7 @@
+
+ #include <linux/device-mapper.h>
+ #include <linux/export.h>
++#include <linux/vmalloc.h>
+
+ #ifdef CONFIG_DM_DEBUG_SPACE_MAPS
+
+@@ -89,13 +90,23 @@ static int ca_create(struct count_array
+
+ ca->nr = nr_blocks;
+ ca->nr_free = nr_blocks;
+- ca->counts = kzalloc(sizeof(*ca->counts) * nr_blocks, GFP_KERNEL);
+- if (!ca->counts)
+- return -ENOMEM;
++
++ if (!nr_blocks)
++ ca->counts = NULL;
++ else {
++ ca->counts = vzalloc(sizeof(*ca->counts) * nr_blocks);
++ if (!ca->counts)
++ return -ENOMEM;
++ }
+
+ return 0;
+ }
+
++static void ca_destroy(struct count_array *ca)
++{
++ vfree(ca->counts);
++}
++
+ static int ca_load(struct count_array *ca, struct dm_space_map *sm)
+ {
+ int r;
+@@ -126,12 +137,14 @@ static int ca_load(struct count_array *c
+ static int ca_extend(struct count_array *ca, dm_block_t extra_blocks)
+ {
+ dm_block_t nr_blocks = ca->nr + extra_blocks;
+- uint32_t *counts = kzalloc(sizeof(*counts) * nr_blocks, GFP_KERNEL);
++ uint32_t *counts = vzalloc(sizeof(*counts) * nr_blocks);
+ if (!counts)
+ return -ENOMEM;
+
+- memcpy(counts, ca->counts, sizeof(*counts) * ca->nr);
+- kfree(ca->counts);
++ if (ca->counts) {
++ memcpy(counts, ca->counts, sizeof(*counts) * ca->nr);
++ ca_destroy(ca);
++ }
+ ca->nr = nr_blocks;
+ ca->nr_free += extra_blocks;
+ ca->counts = counts;
+@@ -151,11 +164,6 @@ static int ca_commit(struct count_array
+ return 0;
+ }
+
+-static void ca_destroy(struct count_array *ca)
+-{
+- kfree(ca->counts);
+-}
+-
+ /*----------------------------------------------------------------*/
+
+ struct sm_checker {
--- /dev/null
+From 25d7cd6faa7ae6ed2565617c3ee2500ccb8a9f7f Mon Sep 17 00:00:00 2001
+From: Mike Snitzer <snitzer@redhat.com>
+Date: Tue, 3 Jul 2012 12:55:33 +0100
+Subject: dm persistent data: fix shadow_info_leak on dm_tm_destroy
+
+From: Mike Snitzer <snitzer@redhat.com>
+
+commit 25d7cd6faa7ae6ed2565617c3ee2500ccb8a9f7f upstream.
+
+Cleanup the shadow table before destroying the transaction manager.
+
+Reference: leak was identified with kmemleak when running
+test_discard_random_sectors in the thinp-test-suite.
+
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Alasdair G Kergon <agk@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/persistent-data/dm-transaction-manager.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/md/persistent-data/dm-transaction-manager.c
++++ b/drivers/md/persistent-data/dm-transaction-manager.c
+@@ -138,6 +138,9 @@ EXPORT_SYMBOL_GPL(dm_tm_create_non_block
+
+ void dm_tm_destroy(struct dm_transaction_manager *tm)
+ {
++ if (!tm->is_clone)
++ wipe_shadow_table(tm);
++
+ kfree(tm);
+ }
+ EXPORT_SYMBOL_GPL(dm_tm_destroy);
--- /dev/null
+From 62662303e7f590fdfbb0070ab820a0ad4267c119 Mon Sep 17 00:00:00 2001
+From: Mike Snitzer <snitzer@redhat.com>
+Date: Tue, 3 Jul 2012 12:55:35 +0100
+Subject: dm persistent data: handle space map checker creation failure
+
+From: Mike Snitzer <snitzer@redhat.com>
+
+commit 62662303e7f590fdfbb0070ab820a0ad4267c119 upstream.
+
+If CONFIG_DM_DEBUG_SPACE_MAPS is enabled and dm_sm_checker_create()
+fails, dm_tm_create_internal() would still return success even though it
+cleaned up all resources it was supposed to have created. This will
+lead to a kernel crash:
+
+general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
+...
+RIP: 0010:[<ffffffff81593659>] [<ffffffff81593659>] dm_bufio_get_block_size+0x9/0x20
+Call Trace:
+ [<ffffffff81599bae>] dm_bm_block_size+0xe/0x10
+ [<ffffffff8159b8b8>] sm_ll_init+0x78/0xd0
+ [<ffffffff8159c1a6>] sm_ll_new_disk+0x16/0xa0
+ [<ffffffff8159c98e>] dm_sm_disk_create+0xfe/0x160
+ [<ffffffff815abf6e>] dm_pool_metadata_open+0x16e/0x6a0
+ [<ffffffff815aa010>] pool_ctr+0x3f0/0x900
+ [<ffffffff8158d565>] dm_table_add_target+0x195/0x450
+ [<ffffffff815904c4>] table_load+0xe4/0x330
+ [<ffffffff815917ea>] ctl_ioctl+0x15a/0x2c0
+ [<ffffffff81591963>] dm_ctl_ioctl+0x13/0x20
+ [<ffffffff8116a4f8>] do_vfs_ioctl+0x98/0x560
+ [<ffffffff8116aa51>] sys_ioctl+0x91/0xa0
+ [<ffffffff81869f52>] system_call_fastpath+0x16/0x1b
+
+Fix the space map checker code to return an appropriate ERR_PTR and have
+dm_sm_disk_create() and dm_tm_create_internal() check for it with
+IS_ERR.
+
+Reported-by: Vivek Goyal <vgoyal@redhat.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Alasdair G Kergon <agk@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/persistent-data/dm-space-map-checker.c | 24 ++++++++++----------
+ drivers/md/persistent-data/dm-space-map-disk.c | 11 ++++++++-
+ drivers/md/persistent-data/dm-transaction-manager.c | 8 +++++-
+ 3 files changed, 28 insertions(+), 15 deletions(-)
+
+--- a/drivers/md/persistent-data/dm-space-map-checker.c
++++ b/drivers/md/persistent-data/dm-space-map-checker.c
+@@ -343,25 +343,25 @@ struct dm_space_map *dm_sm_checker_creat
+ int r;
+ struct sm_checker *smc;
+
+- if (!sm)
+- return NULL;
++ if (IS_ERR_OR_NULL(sm))
++ return ERR_PTR(-EINVAL);
+
+ smc = kmalloc(sizeof(*smc), GFP_KERNEL);
+ if (!smc)
+- return NULL;
++ return ERR_PTR(-ENOMEM);
+
+ memcpy(&smc->sm, &ops_, sizeof(smc->sm));
+ r = ca_create(&smc->old_counts, sm);
+ if (r) {
+ kfree(smc);
+- return NULL;
++ return ERR_PTR(r);
+ }
+
+ r = ca_create(&smc->counts, sm);
+ if (r) {
+ ca_destroy(&smc->old_counts);
+ kfree(smc);
+- return NULL;
++ return ERR_PTR(r);
+ }
+
+ smc->real_sm = sm;
+@@ -371,7 +371,7 @@ struct dm_space_map *dm_sm_checker_creat
+ ca_destroy(&smc->counts);
+ ca_destroy(&smc->old_counts);
+ kfree(smc);
+- return NULL;
++ return ERR_PTR(r);
+ }
+
+ r = ca_commit(&smc->old_counts, &smc->counts);
+@@ -379,7 +379,7 @@ struct dm_space_map *dm_sm_checker_creat
+ ca_destroy(&smc->counts);
+ ca_destroy(&smc->old_counts);
+ kfree(smc);
+- return NULL;
++ return ERR_PTR(r);
+ }
+
+ return &smc->sm;
+@@ -391,25 +391,25 @@ struct dm_space_map *dm_sm_checker_creat
+ int r;
+ struct sm_checker *smc;
+
+- if (!sm)
+- return NULL;
++ if (IS_ERR_OR_NULL(sm))
++ return ERR_PTR(-EINVAL);
+
+ smc = kmalloc(sizeof(*smc), GFP_KERNEL);
+ if (!smc)
+- return NULL;
++ return ERR_PTR(-ENOMEM);
+
+ memcpy(&smc->sm, &ops_, sizeof(smc->sm));
+ r = ca_create(&smc->old_counts, sm);
+ if (r) {
+ kfree(smc);
+- return NULL;
++ return ERR_PTR(r);
+ }
+
+ r = ca_create(&smc->counts, sm);
+ if (r) {
+ ca_destroy(&smc->old_counts);
+ kfree(smc);
+- return NULL;
++ return ERR_PTR(r);
+ }
+
+ smc->real_sm = sm;
+--- a/drivers/md/persistent-data/dm-space-map-disk.c
++++ b/drivers/md/persistent-data/dm-space-map-disk.c
+@@ -290,7 +290,16 @@ struct dm_space_map *dm_sm_disk_create(s
+ dm_block_t nr_blocks)
+ {
+ struct dm_space_map *sm = dm_sm_disk_create_real(tm, nr_blocks);
+- return dm_sm_checker_create_fresh(sm);
++ struct dm_space_map *smc;
++
++ if (IS_ERR_OR_NULL(sm))
++ return sm;
++
++ smc = dm_sm_checker_create_fresh(sm);
++ if (IS_ERR(smc))
++ dm_sm_destroy(sm);
++
++ return smc;
+ }
+ EXPORT_SYMBOL_GPL(dm_sm_disk_create);
+
+--- a/drivers/md/persistent-data/dm-transaction-manager.c
++++ b/drivers/md/persistent-data/dm-transaction-manager.c
+@@ -345,8 +345,10 @@ static int dm_tm_create_internal(struct
+ }
+
+ *sm = dm_sm_checker_create(inner);
+- if (!*sm)
++ if (IS_ERR(*sm)) {
++ r = PTR_ERR(*sm);
+ goto bad2;
++ }
+
+ } else {
+ r = dm_bm_write_lock(dm_tm_get_bm(*tm), sb_location,
+@@ -365,8 +367,10 @@ static int dm_tm_create_internal(struct
+ }
+
+ *sm = dm_sm_checker_create(inner);
+- if (!*sm)
++ if (IS_ERR(*sm)) {
++ r = PTR_ERR(*sm);
+ goto bad2;
++ }
+ }
+
+ return 0;
--- /dev/null
+From 18068bdd5f59229623b2fa518a6389e346642b0d Mon Sep 17 00:00:00 2001
+From: Milan Broz <mbroz@redhat.com>
+Date: Tue, 3 Jul 2012 12:55:41 +0100
+Subject: dm: verity fix documentation
+
+From: Milan Broz <mbroz@redhat.com>
+
+commit 18068bdd5f59229623b2fa518a6389e346642b0d upstream.
+
+Veritysetup is now part of cryptsetup package.
+Remove on-disk header description (which is not parsed in kernel)
+and point users to cryptsetup where it the format is documented.
+Mention units for block size paramaters.
+Fix target line specification and dmsetup parameters.
+
+Signed-off-by: Milan Broz <mbroz@redhat.com>
+Signed-off-by: Alasdair G Kergon <agk@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ Documentation/device-mapper/verity.txt | 133 +++++++++++----------------------
+ 1 file changed, 47 insertions(+), 86 deletions(-)
+
+--- a/Documentation/device-mapper/verity.txt
++++ b/Documentation/device-mapper/verity.txt
+@@ -7,39 +7,39 @@ This target is read-only.
+
+ Construction Parameters
+ =======================
+- <version> <dev> <hash_dev> <hash_start>
++ <version> <dev> <hash_dev>
+ <data_block_size> <hash_block_size>
+ <num_data_blocks> <hash_start_block>
+ <algorithm> <digest> <salt>
+
+ <version>
+- This is the version number of the on-disk format.
++ This is the type of the on-disk hash format.
+
+ 0 is the original format used in the Chromium OS.
+- The salt is appended when hashing, digests are stored continuously and
+- the rest of the block is padded with zeros.
++ The salt is appended when hashing, digests are stored continuously and
++ the rest of the block is padded with zeros.
+
+ 1 is the current format that should be used for new devices.
+- The salt is prepended when hashing and each digest is
+- padded with zeros to the power of two.
++ The salt is prepended when hashing and each digest is
++ padded with zeros to the power of two.
+
+ <dev>
+- This is the device containing the data the integrity of which needs to be
++ This is the device containing data, the integrity of which needs to be
+ checked. It may be specified as a path, like /dev/sdaX, or a device number,
+ <major>:<minor>.
+
+ <hash_dev>
+- This is the device that that supplies the hash tree data. It may be
++ This is the device that supplies the hash tree data. It may be
+ specified similarly to the device path and may be the same device. If the
+- same device is used, the hash_start should be outside of the dm-verity
+- configured device size.
++ same device is used, the hash_start should be outside the configured
++ dm-verity device.
+
+ <data_block_size>
+- The block size on a data device. Each block corresponds to one digest on
+- the hash device.
++ The block size on a data device in bytes.
++ Each block corresponds to one digest on the hash device.
+
+ <hash_block_size>
+- The size of a hash block.
++ The size of a hash block in bytes.
+
+ <num_data_blocks>
+ The number of data blocks on the data device. Additional blocks are
+@@ -65,7 +65,7 @@ Construction Parameters
+ Theory of operation
+ ===================
+
+-dm-verity is meant to be setup as part of a verified boot path. This
++dm-verity is meant to be set up as part of a verified boot path. This
+ may be anything ranging from a boot using tboot or trustedgrub to just
+ booting from a known-good device (like a USB drive or CD).
+
+@@ -73,20 +73,20 @@ When a dm-verity device is configured, i
+ has been authenticated in some way (cryptographic signatures, etc).
+ After instantiation, all hashes will be verified on-demand during
+ disk access. If they cannot be verified up to the root node of the
+-tree, the root hash, then the I/O will fail. This should identify
++tree, the root hash, then the I/O will fail. This should detect
+ tampering with any data on the device and the hash data.
+
+ Cryptographic hashes are used to assert the integrity of the device on a
+-per-block basis. This allows for a lightweight hash computation on first read
+-into the page cache. Block hashes are stored linearly-aligned to the nearest
+-block the size of a page.
++per-block basis. This allows for a lightweight hash computation on first read
++into the page cache. Block hashes are stored linearly, aligned to the nearest
++block size.
+
+ Hash Tree
+ ---------
+
+ Each node in the tree is a cryptographic hash. If it is a leaf node, the hash
+-is of some block data on disk. If it is an intermediary node, then the hash is
+-of a number of child nodes.
++of some data block on disk is calculated. If it is an intermediary node,
++the hash of a number of child nodes is calculated.
+
+ Each entry in the tree is a collection of neighboring nodes that fit in one
+ block. The number is determined based on block_size and the size of the
+@@ -110,63 +110,23 @@ alg = sha256, num_blocks = 32768, block_
+ On-disk format
+ ==============
+
+-Below is the recommended on-disk format. The verity kernel code does not
+-read the on-disk header. It only reads the hash blocks which directly
+-follow the header. It is expected that a user-space tool will verify the
+-integrity of the verity_header and then call dmsetup with the correct
+-parameters. Alternatively, the header can be omitted and the dmsetup
+-parameters can be passed via the kernel command-line in a rooted chain
+-of trust where the command-line is verified.
+-
+-The on-disk format is especially useful in cases where the hash blocks
+-are on a separate partition. The magic number allows easy identification
+-of the partition contents. Alternatively, the hash blocks can be stored
+-in the same partition as the data to be verified. In such a configuration
+-the filesystem on the partition would be sized a little smaller than
+-the full-partition, leaving room for the hash blocks.
+-
+-struct superblock {
+- uint8_t signature[8]
+- "verity\0\0";
+-
+- uint8_t version;
+- 1 - current format
+-
+- uint8_t data_block_bits;
+- log2(data block size)
+-
+- uint8_t hash_block_bits;
+- log2(hash block size)
+-
+- uint8_t pad1[1];
+- zero padding
+-
+- uint16_t salt_size;
+- big-endian salt size
+-
+- uint8_t pad2[2];
+- zero padding
+-
+- uint32_t data_blocks_hi;
+- big-endian high 32 bits of the 64-bit number of data blocks
+-
+- uint32_t data_blocks_lo;
+- big-endian low 32 bits of the 64-bit number of data blocks
+-
+- uint8_t algorithm[16];
+- cryptographic algorithm
+-
+- uint8_t salt[384];
+- salt (the salt size is specified above)
+-
+- uint8_t pad3[88];
+- zero padding to 512-byte boundary
+-}
++The verity kernel code does not read the verity metadata on-disk header.
++It only reads the hash blocks which directly follow the header.
++It is expected that a user-space tool will verify the integrity of the
++verity header.
++
++Alternatively, the header can be omitted and the dmsetup parameters can
++be passed via the kernel command-line in a rooted chain of trust where
++the command-line is verified.
+
+ Directly following the header (and with sector number padded to the next hash
+ block boundary) are the hash blocks which are stored a depth at a time
+ (starting from the root), sorted in order of increasing index.
+
++The full specification of kernel parameters and on-disk metadata format
++is available at the cryptsetup project's wiki page
++ http://code.google.com/p/cryptsetup/wiki/DMVerity
++
+ Status
+ ======
+ V (for Valid) is returned if every check performed so far was valid.
+@@ -174,21 +134,22 @@ If any check failed, C (for Corruption)
+
+ Example
+ =======
+-
+-Setup a device:
+- dmsetup create vroot --table \
+- "0 2097152 "\
+- "verity 1 /dev/sda1 /dev/sda2 4096 4096 2097152 1 "\
++Set up a device:
++ # dmsetup create vroot --readonly --table \
++ "0 2097152 verity 1 /dev/sda1 /dev/sda2 4096 4096 262144 1 sha256 "\
+ "4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076 "\
+ "1234000000000000000000000000000000000000000000000000000000000000"
+
+ A command line tool veritysetup is available to compute or verify
+-the hash tree or activate the kernel driver. This is available from
+-the LVM2 upstream repository and may be supplied as a package called
+-device-mapper-verity-tools:
+- git://sources.redhat.com/git/lvm2
+- http://sourceware.org/git/?p=lvm2.git
+- http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/verity?cvsroot=lvm2
+-
+-veritysetup -a vroot /dev/sda1 /dev/sda2 \
+- 4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076
++the hash tree or activate the kernel device. This is available from
++the cryptsetup upstream repository http://code.google.com/p/cryptsetup/
++(as a libcryptsetup extension).
++
++Create hash on the device:
++ # veritysetup format /dev/sda1 /dev/sda2
++ ...
++ Root hash: 4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076
++
++Activate the device:
++ # veritysetup create vroot /dev/sda1 /dev/sda2 \
++ 4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076
--- /dev/null
+From fc448a18ae6219af9a73257b1fbcd009efab4a81 Mon Sep 17 00:00:00 2001
+From: NeilBrown <neilb@suse.de>
+Date: Tue, 3 Jul 2012 10:37:30 +1000
+Subject: md/raid10: Don't try to recovery unmatched (and unused) chunks.
+
+From: NeilBrown <neilb@suse.de>
+
+commit fc448a18ae6219af9a73257b1fbcd009efab4a81 upstream.
+
+If a RAID10 has an odd number of chunks - as might happen when there
+are an odd number of devices - the last chunk has no pair and so is
+not mirrored. We don't store data there, but when recovering the last
+device in an array we retry to recover that last chunk from a
+non-existent location. This results in an error, and the recovery
+aborts.
+
+When we get to that last chunk we should just stop - there is nothing
+more to do anyway.
+
+This bug has been present since the introduction of RAID10, so the
+patch is appropriate for any -stable kernel.
+
+Reported-by: Christian Balzer <chibi@gol.com>
+Tested-by: Christian Balzer <chibi@gol.com>
+Signed-off-by: NeilBrown <neilb@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/raid10.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/md/raid10.c
++++ b/drivers/md/raid10.c
+@@ -2772,6 +2772,12 @@ static sector_t sync_request(struct mdde
+ /* want to reconstruct this device */
+ rb2 = r10_bio;
+ sect = raid10_find_virt(conf, sector_nr, i);
++ if (sect >= mddev->resync_max_sectors) {
++ /* last stripe is not complete - don't
++ * try to recover this sector.
++ */
++ continue;
++ }
+ /* Unless we are doing a full sync, or a replacement
+ * we only need to recover the block if it is set in
+ * the bitmap
--- /dev/null
+From 055d3747dbf00ce85c6872ecca4d466638e80c22 Mon Sep 17 00:00:00 2001
+From: NeilBrown <neilb@suse.de>
+Date: Tue, 3 Jul 2012 15:55:33 +1000
+Subject: md/raid10: fix failure when trying to repair a read error.
+
+From: NeilBrown <neilb@suse.de>
+
+commit 055d3747dbf00ce85c6872ecca4d466638e80c22 upstream.
+
+commit 58c54fcca3bac5bf9290cfed31c76e4c4bfbabaf
+ md/raid10: handle further errors during fix_read_error better.
+
+in 3.1 added "r10_sync_page_io" which takes an IO size in sectors.
+But we were passing the IO size in bytes!!!
+This resulting in bio_add_page failing, and empty request being sent
+down, and a consequent BUG_ON in scsi_lib.
+
+[fix missing space in error message at same time]
+
+This fix is suitable for 3.1.y and later.
+
+Reported-by: Christian Balzer <chibi@gol.com>
+Signed-off-by: NeilBrown <neilb@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/raid10.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/md/raid10.c
++++ b/drivers/md/raid10.c
+@@ -2209,7 +2209,7 @@ static void fix_read_error(struct r10con
+ if (r10_sync_page_io(rdev,
+ r10_bio->devs[sl].addr +
+ sect,
+- s<<9, conf->tmppage, WRITE)
++ s, conf->tmppage, WRITE)
+ == 0) {
+ /* Well, this device is dead */
+ printk(KERN_NOTICE
+@@ -2246,7 +2246,7 @@ static void fix_read_error(struct r10con
+ switch (r10_sync_page_io(rdev,
+ r10_bio->devs[sl].addr +
+ sect,
+- s<<9, conf->tmppage,
++ s, conf->tmppage,
+ READ)) {
+ case 0:
+ /* Well, this device is dead */
+@@ -2407,7 +2407,7 @@ read_more:
+ slot = r10_bio->read_slot;
+ printk_ratelimited(
+ KERN_ERR
+- "md/raid10:%s: %s: redirecting"
++ "md/raid10:%s: %s: redirecting "
+ "sector %llu to another mirror\n",
+ mdname(mddev),
+ bdevname(rdev->bdev, b),
--- /dev/null
+From 1850753d2e6d9ca7856581ca5d3cf09521e6a5d7 Mon Sep 17 00:00:00 2001
+From: majianpeng <majianpeng@gmail.com>
+Date: Tue, 3 Jul 2012 12:11:54 +1000
+Subject: md/raid5: In ops_run_io, inc nr_pending before calling md_wait_for_blocked_rdev
+
+From: majianpeng <majianpeng@gmail.com>
+
+commit 1850753d2e6d9ca7856581ca5d3cf09521e6a5d7 upstream.
+
+In ops_run_io(), the call to md_wait_for_blocked_rdev will decrement
+nr_pending so we lose the reference we hold on the rdev.
+So atomic_inc it first to maintain the reference.
+
+This bug was introduced by commit 73e92e51b7969ef5477d
+ md/raid5. Don't write to known bad block on doubtful devices.
+
+which appeared in 3.0, so patch is suitable for stable kernels since
+then.
+
+Signed-off-by: majianpeng <majianpeng@gmail.com>
+Signed-off-by: NeilBrown <neilb@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/raid5.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/md/raid5.c
++++ b/drivers/md/raid5.c
+@@ -583,6 +583,12 @@ static void ops_run_io(struct stripe_hea
+ * a chance*/
+ md_check_recovery(conf->mddev);
+ }
++ /*
++ * Because md_wait_for_blocked_rdev
++ * will dec nr_pending, we must
++ * increment it first.
++ */
++ atomic_inc(&rdev->nr_pending);
+ md_wait_for_blocked_rdev(rdev, conf->mddev);
+ } else {
+ /* Acknowledged bad block - skip the write */
remoteproc-omap-fix-randconfig-unmet-direct-dependencies.patch
remoteproc-fix-missing-config_fw_loader-configurations.patch
hwspinlock-core-use-global-id-to-register-hwspinlocks-on-multiple-devices.patch
+md-raid10-don-t-try-to-recovery-unmatched-and-unused-chunks.patch
+md-raid10-fix-failure-when-trying-to-repair-a-read-error.patch
+md-raid5-in-ops_run_io-inc-nr_pending-before-calling-md_wait_for_blocked_rdev.patch
+dm-verity-fix-documentation.patch
+dm-persistent-data-fix-shadow_info_leak-on-dm_tm_destroy.patch
+dm-persistent-data-handle-space-map-checker-creation-failure.patch
+dm-persistent-data-fix-allocation-failure-in-space-map-checker-init.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
