kernel/git/stable/linux-stable.git/drivers/md/raid5.c, branch linux-2.6.32.y

md/raid5: don't record new size if resize_stripes fails.

2015-09-18T11:52:00+00:00

commit 6e9eac2dcee5e19f125967dd2be3e36558c42fff upstream. If any memory allocation in resize_stripes fails we will return -ENOMEM, but in some cases we update conf->pool_size anyway. This means that if we try again, the allocations will be assumed to be larger than they are, and badness results. So only update pool_size if there is no error. This bug was introduced in 2.6.17 and the patch is suitable for -stable. Fixes: ad01c9e3752f ("[PATCH] md: Allow stripes to be expanded in preparation for expanding an array") Signed-off-by: NeilBrown Signed-off-by: Ben Hutchings (cherry picked from commit c20694a054e903745591f4f85b39ecbce4e58349) Signed-off-by: Willy Tarreau

md/raid6: Fix misapplied backport in 2.6.32.64

2014-12-13T14:16:18+00:00

Upstream commit 9c4bdf697c39 ("md/raid6: avoid data corruption during recovery of double-degraded RAID6") changes handle_stripe(), but we have separate functions for RAID5 and RAID6 and need to apply the change to handle_stripe6(). When cherry-picked, the change was wrongly applied to handle_stripe5(). Signed-off-by: Ben Hutchings Signed-off-by: Willy Tarreau

md/raid6: avoid data corruption during recovery of double-degraded RAID6

2014-11-23T09:55:49+00:00

During recovery of a double-degraded RAID6 it is possible for some blocks not to be recovered properly, leading to corruption. If a write happens to one block in a stripe that would be written to a missing device, and at the same time that stripe is recovering data to the other missing device, then that recovered data may not be written. This patch skips, in the double-degraded case, an optimisation that is only safe for single-degraded arrays. Bug was introduced in 2.6.32 and fix is suitable for any kernel since then. In an older kernel with separate handle_stripe5() and handle_stripe6() functions the patch must change handle_stripe6(). Cc: stable@vger.kernel.org (2.6.32+) Fixes: 6c0069c0ae9659e3a91b68eaed06a5c6c37f45c8 Cc: Yuri Tikhonov Cc: Dan Williams Reported-by: "Manibalan P" Tested-by: "Manibalan P" Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1090423 Signed-off-by: NeilBrown Acked-by: Dan Williams (cherry picked from commit 9c4bdf697c39805078392d5ddbbba5ae5680e0dd) Signed-off-by: Willy Tarreau

md/raid5: abort any pending parity operations when array fails.

2011-11-26T17:10:34+00:00

commit 9a3f530f39f4490eaa18b02719fb74ce5f4d2d86 upstream. When the number of failed devices exceeds the allowed number we must abort any active parity operations (checks or updates) as they are no longer meaningful, and can lead to a BUG_ON in handle_parity_checks6. This bug was introduce by commit 6c0069c0ae9659e3a91b68eaed06a5c6c37f45c8 in 2.6.29. Reported-by: Manish Katiyar Tested-by: Manish Katiyar Acked-by: Dan Williams Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman

md/raid5: fix FUA request handling in ops_run_io()

2011-06-23T22:24:08+00:00

commit b062962edb086011e94ec4d9eb3f6a6d814f2a8f upstream. Commit e9c7469bb4f5 ("md: implment REQ_FLUSH/FUA support") introduced R5_WantFUA flag and set rw to WRITE_FUA in that case. However remaining code still checks whether rw is exactly same as WRITE or not, so FUAed-write ends up with being treated as READ. Fix it. This bug has been present since 2.6.37 and the fix is suitable for any -stable kernel since then. It is not clear why this has not caused more problems. Cc: Tejun Heo Signed-off-by: Namhyung Kim Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman

md/raid5: fix raid5_set_bi_hw_segments

2011-06-23T22:24:08+00:00

commit 9b2dc8b665932a8e681a7ab3237f60475e75e161 upstream. The @bio->bi_phys_segments consists of active stripes count in the lower 16 bits and processed stripes count in the upper 16 bits. So logical-OR operator should be bitwise one. This bug has been present since 2.6.27 and the fix is suitable for any -stable kernel since then. Fortunately the bad code is only used on error paths and is relatively unlikely to be hit. Signed-off-by: Namhyung Kim Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman

md/raid6: Fix raid-6 read-error correction in degraded state

2010-05-12T21:57:15+00:00

commit 87aa63000c484bfb9909989316f615240dfee018 upstream. Fix: Raid-6 was not trying to correct a read-error when in singly-degraded state and was instead dropping one more device, going to doubly-degraded state. This patch fixes this behaviour. Tested-by: Janos Haar Signed-off-by: Gabriele A. Trombetti Reported-by: Janos Haar Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman

md/raid5: fix previous patch.

2010-05-12T21:56:59+00:00

commit 6e3b96ed610e5a1838e62ddae9fa0c3463f235fa upstream. Previous patch changes stripe and chunk_number to sector_t but mistakenly did not update all of the divisions to use sector_dev(). This patch changes all the those divisions (actually the '%' operator) to sector_div. Signed-off-by: NeilBrown Tested-by: Stefan Lippers-Hollmann Signed-off-by: Greg Kroah-Hartman

md/raid5: allow for more than 2^31 chunks.

2010-05-12T21:56:59+00:00

commit 35f2a591192d0a5d9f7fc696869c76f0b8e49c3d upstream. With many large drives and small chunk sizes it is possible to create a RAID5 with more than 2^31 chunks. Make sure this works. Reported-by: Brett King Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman

md: fix 'degraded' calculation when starting a reshape.

2010-02-23T15:37:51+00:00

commit 9eb07c259207d048e3ee8be2a77b2a4680b1edd4 upstream. This code was written long ago when it was not possible to reshape a degraded array. Now it is so the current level of degraded-ness needs to be taken in to account. Also newly addded devices should only reduce degradedness if they are deemed to be in-sync. In particular, if you convert a RAID5 to a RAID6, and increase the number of devices at the same time, then the 5->6 conversion will make the array degraded so the current code will produce a wrong value for 'degraded' - "-1" to be precise. If the reshape runs to completion end_reshape will calculate a correct new value for 'degraded', but if a device fails during the reshape an incorrect decision might be made based on the incorrect value of "degraded". This patch is suitable for 2.6.32-stable and if they are still open, 2.6.31-stable and 2.6.30-stable as well. Reported-by: Michael Evans Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman