3.14-stable patches

added patches:
	md-raid5-fetch_block-must-fetch-all-the-blocks-handle_stripe_dirtying-wants.patch

diff --git a/queue-3.14/md-raid5-fetch_block-must-fetch-all-the-blocks-handle_stripe_dirtying-wants.patch b/queue-3.14/md-raid5-fetch_block-must-fetch-all-the-blocks-handle_stripe_dirtying-wants.patch
new file mode 100644 (file)
index 0000000..4c37870
--- /dev/null
+++ b/queue-3.14/md-raid5-fetch_block-must-fetch-all-the-blocks-handle_stripe_dirtying-wants.patch
@@ -0,0 +1,47 @@
+From 108cef3aa41669610e1836fe638812dd067d72de Mon Sep 17 00:00:00 2001
+From: NeilBrown <neilb@suse.de>
+Date: Wed, 3 Dec 2014 16:07:58 +1100
+Subject: md/raid5: fetch_block must fetch all the blocks handle_stripe_dirtying wants.
+
+From: NeilBrown <neilb@suse.de>
+
+commit 108cef3aa41669610e1836fe638812dd067d72de upstream.
+
+It is critical that fetch_block() and handle_stripe_dirtying()
+are consistent in their analysis of what needs to be loaded.
+Otherwise raid5 can wait forever for a block that won't be loaded.
+
+Currently when writing to a RAID5 that is resyncing, to a location
+beyond the resync offset, handle_stripe_dirtying chooses a
+reconstruct-write cycle, but fetch_block() assumes a
+read-modify-write, and a lockup can happen.
+
+So treat that case just like RAID6, just as we do in
+handle_stripe_dirtying.  RAID6 always does reconstruct-write.
+
+This bug was introduced when the behaviour of handle_stripe_dirtying
+was changed in 3.7, so the patch is suitable for any kernel since,
+though it will need careful merging for some versions.
+
+Cc: stable@vger.kernel.org (v3.7+)
+Fixes: a7854487cd7128a30a7f4f5259de9f67d5efb95f
+Reported-by: Henry Cai <henryplusplus@gmail.com>
+Signed-off-by: NeilBrown <neilb@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/raid5.c |    3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/md/raid5.c
++++ b/drivers/md/raid5.c
+@@ -2896,7 +2896,8 @@ static int fetch_block(struct stripe_hea
+            (s->failed >= 2 && fdev[1]->toread) ||
+            (sh->raid_conf->level <= 5 && s->failed && fdev[0]->towrite &&
+             !test_bit(R5_OVERWRITE, &fdev[0]->flags)) ||
+-           (sh->raid_conf->level == 6 && s->failed && s->to_write))) {
++           ((sh->raid_conf->level == 6 || sh->sector >= sh->raid_conf->mddev->recovery_cp)
++            && s->failed && s->to_write))) {
+               /* we would like to get this block, possibly by computing it,
+                * otherwise read it if the backing disk is insync
+                */

diff --git a/queue-3.14/series b/queue-3.14/series
index 98ac2a044f29d4d369a376ef664683f981eb5e7f..cb2c2d3145bde1830d155923b946f422778eebdc 100644 (file)
--- a/queue-3.14/series
+++ b/queue-3.14/series
@@ -74,3 +74,4 @@ mm-vmscan-only-update-per-cpu-thresholds-for-online-cpu.patch
 mm-page_alloc-abort-fair-zone-allocation-policy-when-remotes-nodes-are-encountered.patch
 mm-page_alloc-reduce-cost-of-the-fair-zone-allocation-policy.patch
 mm-get-rid-of-radix-tree-gfp-mask-for-pagecache_get_page.patch
+md-raid5-fetch_block-must-fetch-all-the-blocks-handle_stripe_dirtying-wants.patch