mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
synced 2025-01-10 07:10:27 +00:00
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 <henryplusplus@gmail.com> Signed-off-by: NeilBrown <neilb@suse.de>
This commit is contained in:
parent
3a18ca0613
commit
108cef3aa4
@ -2917,8 +2917,11 @@ static int fetch_block(struct stripe_head *sh, struct stripe_head_state *s,
|
||||
(sh->raid_conf->level <= 5 && s->failed && fdev[0]->towrite &&
|
||||
(!test_bit(R5_Insync, &dev->flags) || test_bit(STRIPE_PREREAD_ACTIVE, &sh->state)) &&
|
||||
!test_bit(R5_OVERWRITE, &fdev[0]->flags)) ||
|
||||
(sh->raid_conf->level == 6 && s->failed && s->to_write &&
|
||||
s->to_write - s->non_overwrite < sh->raid_conf->raid_disks - 2 &&
|
||||
((sh->raid_conf->level == 6 ||
|
||||
sh->sector >= sh->raid_conf->mddev->recovery_cp)
|
||||
&& s->failed && s->to_write &&
|
||||
(s->to_write - s->non_overwrite <
|
||||
sh->raid_conf->raid_disks - sh->raid_conf->max_degraded) &&
|
||||
(!test_bit(R5_Insync, &dev->flags) || test_bit(STRIPE_PREREAD_ACTIVE, &sh->state))))) {
|
||||
/* we would like to get this block, possibly by computing it,
|
||||
* otherwise read it if the backing disk is insync
|
||||
|
Loading…
x
Reference in New Issue
Block a user