aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorNeilBrown <neilb@suse.de>2010-06-17 17:41:03 +1000
committerNeilBrown <neilb@suse.de>2010-06-24 13:35:49 +1000
commit2f115882499f3e5eca33d1df07b8876cc752a1ff (patch)
tree8f9f1e723be1b4dd0e5fa7592a69245a704d8440
parent415e72d034c50520ddb7ff79e7d1792c1306f0c9 (diff)
downloadglint-2f115882499f3e5eca33d1df07b8876cc752a1ff.tar.gz
md/raid5: add a missing 'continue' in a loop.
As the comment says, the tail of this loop only applies to devices that are not fully in sync, so if In_sync was set, we should avoid the rest of the loop. This bug will hardly ever cause an actual problem. The worst it can do is allow an array to be assembled that is dirty and degraded, which is not generally a good idea (without warning the sysadmin first). This will only happen if the array is RAID4 or a RAID5/6 in an intermediate state during a reshape and so has one drive that is all 'parity' - no data - while some other device has failed. This is certainly possible, but not at all common. Signed-off-by: NeilBrown <neilb@suse.de>
-rw-r--r--drivers/md/raid5.c4
1 files changed, 3 insertions, 1 deletions
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 09f07dadf4044..66cd479733987 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -5057,8 +5057,10 @@ static int run(mddev_t *mddev)
list_for_each_entry(rdev, &mddev->disks, same_set) {
if (rdev->raid_disk < 0)
continue;
- if (test_bit(In_sync, &rdev->flags))
+ if (test_bit(In_sync, &rdev->flags)) {
working_disks++;
+ continue;
+ }
/* This disc is not fully in-sync. However if it
* just stored parity (beyond the recovery_offset),
* when we don't need to be concerned about the