From: NeilBrown Date: Wed, 3 Dec 2014 05:07:58 +0000 (+1100) Subject: md/raid5: fetch_block must fetch all the blocks handle_stripe_dirtying wants. X-Git-Tag: omap-for-v3.19/fixes-rc1~92^2~2 X-Git-Url: http://git.openpandora.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=108cef3aa41669610e1836fe638812dd067d72de;p=pandora-kernel.git md/raid5: fetch_block must fetch all the blocks handle_stripe_dirtying wants. 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 Signed-off-by: NeilBrown --- Reading git-diff-tree failed