From: Greg Kroah-Hartman Date: Wed, 11 Jul 2012 13:31:08 +0000 (-0700) Subject: 3.4-stable patches X-Git-Tag: v3.0.37~25 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=bc1f5ff51143b091804a09f6cb4a14c98f0e444c;p=thirdparty%2Fkernel%2Fstable-queue.git 3.4-stable patches added patches: dm-persistent-data-fix-allocation-failure-in-space-map-checker-init.patch dm-persistent-data-fix-shadow_info_leak-on-dm_tm_destroy.patch dm-persistent-data-handle-space-map-checker-creation-failure.patch dm-verity-fix-documentation.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 --- diff --git a/queue-3.4/dm-persistent-data-fix-allocation-failure-in-space-map-checker-init.patch b/queue-3.4/dm-persistent-data-fix-allocation-failure-in-space-map-checker-init.patch new file mode 100644 index 00000000000..d29064ef029 --- /dev/null +++ b/queue-3.4/dm-persistent-data-fix-allocation-failure-in-space-map-checker-init.patch @@ -0,0 +1,92 @@ +From b0239faaf87c38bb419c9264bf20817438ddc3a9 Mon Sep 17 00:00:00 2001 +From: Mike Snitzer +Date: Tue, 3 Jul 2012 12:55:37 +0100 +Subject: dm persistent data: fix allocation failure in space map checker init + +From: Mike Snitzer + +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 +Signed-off-by: Mike Snitzer +Signed-off-by: Alasdair G Kergon +Signed-off-by: Greg Kroah-Hartman + +--- + 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 + #include ++#include + + #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 { diff --git a/queue-3.4/dm-persistent-data-fix-shadow_info_leak-on-dm_tm_destroy.patch b/queue-3.4/dm-persistent-data-fix-shadow_info_leak-on-dm_tm_destroy.patch new file mode 100644 index 00000000000..893518fae2d --- /dev/null +++ b/queue-3.4/dm-persistent-data-fix-shadow_info_leak-on-dm_tm_destroy.patch @@ -0,0 +1,34 @@ +From 25d7cd6faa7ae6ed2565617c3ee2500ccb8a9f7f Mon Sep 17 00:00:00 2001 +From: Mike Snitzer +Date: Tue, 3 Jul 2012 12:55:33 +0100 +Subject: dm persistent data: fix shadow_info_leak on dm_tm_destroy + +From: Mike Snitzer + +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 +Signed-off-by: Alasdair G Kergon +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-3.4/dm-persistent-data-handle-space-map-checker-creation-failure.patch b/queue-3.4/dm-persistent-data-handle-space-map-checker-creation-failure.patch new file mode 100644 index 00000000000..08b4afdfa4b --- /dev/null +++ b/queue-3.4/dm-persistent-data-handle-space-map-checker-creation-failure.patch @@ -0,0 +1,175 @@ +From 62662303e7f590fdfbb0070ab820a0ad4267c119 Mon Sep 17 00:00:00 2001 +From: Mike Snitzer +Date: Tue, 3 Jul 2012 12:55:35 +0100 +Subject: dm persistent data: handle space map checker creation failure + +From: Mike Snitzer + +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:[] [] dm_bufio_get_block_size+0x9/0x20 +Call Trace: + [] dm_bm_block_size+0xe/0x10 + [] sm_ll_init+0x78/0xd0 + [] sm_ll_new_disk+0x16/0xa0 + [] dm_sm_disk_create+0xfe/0x160 + [] dm_pool_metadata_open+0x16e/0x6a0 + [] pool_ctr+0x3f0/0x900 + [] dm_table_add_target+0x195/0x450 + [] table_load+0xe4/0x330 + [] ctl_ioctl+0x15a/0x2c0 + [] dm_ctl_ioctl+0x13/0x20 + [] do_vfs_ioctl+0x98/0x560 + [] sys_ioctl+0x91/0xa0 + [] 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 +Signed-off-by: Mike Snitzer +Signed-off-by: Alasdair G Kergon +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-3.4/dm-verity-fix-documentation.patch b/queue-3.4/dm-verity-fix-documentation.patch new file mode 100644 index 00000000000..fe183dd124c --- /dev/null +++ b/queue-3.4/dm-verity-fix-documentation.patch @@ -0,0 +1,227 @@ +From 18068bdd5f59229623b2fa518a6389e346642b0d Mon Sep 17 00:00:00 2001 +From: Milan Broz +Date: Tue, 3 Jul 2012 12:55:41 +0100 +Subject: dm: verity fix documentation + +From: Milan Broz + +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 +Signed-off-by: Alasdair G Kergon +Signed-off-by: Greg Kroah-Hartman + +--- + 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 + ======================= +- ++ + + + + + +- 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. + + +- 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, + :. + + +- 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. + + +- 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. + + +- The size of a hash block. ++ The size of a hash block in bytes. + + + 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 diff --git a/queue-3.4/md-raid10-don-t-try-to-recovery-unmatched-and-unused-chunks.patch b/queue-3.4/md-raid10-don-t-try-to-recovery-unmatched-and-unused-chunks.patch new file mode 100644 index 00000000000..3281c49b523 --- /dev/null +++ b/queue-3.4/md-raid10-don-t-try-to-recovery-unmatched-and-unused-chunks.patch @@ -0,0 +1,46 @@ +From fc448a18ae6219af9a73257b1fbcd009efab4a81 Mon Sep 17 00:00:00 2001 +From: NeilBrown +Date: Tue, 3 Jul 2012 10:37:30 +1000 +Subject: md/raid10: Don't try to recovery unmatched (and unused) chunks. + +From: NeilBrown + +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 +Tested-by: Christian Balzer +Signed-off-by: NeilBrown +Signed-off-by: Greg Kroah-Hartman + +--- + 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 diff --git a/queue-3.4/md-raid10-fix-failure-when-trying-to-repair-a-read-error.patch b/queue-3.4/md-raid10-fix-failure-when-trying-to-repair-a-read-error.patch new file mode 100644 index 00000000000..1f6547a0e34 --- /dev/null +++ b/queue-3.4/md-raid10-fix-failure-when-trying-to-repair-a-read-error.patch @@ -0,0 +1,58 @@ +From 055d3747dbf00ce85c6872ecca4d466638e80c22 Mon Sep 17 00:00:00 2001 +From: NeilBrown +Date: Tue, 3 Jul 2012 15:55:33 +1000 +Subject: md/raid10: fix failure when trying to repair a read error. + +From: NeilBrown + +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 +Signed-off-by: NeilBrown +Signed-off-by: Greg Kroah-Hartman + +--- + 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), diff --git a/queue-3.4/md-raid5-in-ops_run_io-inc-nr_pending-before-calling-md_wait_for_blocked_rdev.patch b/queue-3.4/md-raid5-in-ops_run_io-inc-nr_pending-before-calling-md_wait_for_blocked_rdev.patch new file mode 100644 index 00000000000..0258bf942e7 --- /dev/null +++ b/queue-3.4/md-raid5-in-ops_run_io-inc-nr_pending-before-calling-md_wait_for_blocked_rdev.patch @@ -0,0 +1,42 @@ +From 1850753d2e6d9ca7856581ca5d3cf09521e6a5d7 Mon Sep 17 00:00:00 2001 +From: majianpeng +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 + +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 +Signed-off-by: NeilBrown +Signed-off-by: Greg Kroah-Hartman + +--- + 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 */ diff --git a/queue-3.4/series b/queue-3.4/series index 0aff4a9ce36..f63a51509ed 100644 --- a/queue-3.4/series +++ b/queue-3.4/series @@ -124,3 +124,10 @@ e1000e-remove-use-of-ip-payload-checksum.patch 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