]> err.no Git - linux-2.6/commitdiff
Don't acknowlege that stripe-expand is complete until it really is.
authorNeil Brown <neilb@notabene.brown>
Fri, 27 Jun 2008 22:31:14 +0000 (08:31 +1000)
committerNeil Brown <neilb@notabene.brown>
Fri, 27 Jun 2008 22:31:14 +0000 (08:31 +1000)
We shouldn't acknowledge that a stripe has been expanded (When
reshaping a raid5 by adding a device) until the moved data has
actually been written out.  However we are currently
acknowledging (by calling md_done_sync) when the POST_XOR
is complete and before the write.

So track in s.locked whether there are pending writes, and don't
call md_done_sync yet if there are.

Note: we all set R5_LOCKED on devices which are are about to
read from.  This probably isn't technically necessary, but is
usually done when writing a block, and justifies the use of
s.locked here.

This bug can lead to a crash if an array is stopped while an reshape
is in progress.

Cc: <stable@kernel.org>
Signed-off-by: Neil Brown <neilb@suse.de>
drivers/md/raid5.c

index 475fba4d371e038d3f2111df756cf93a6d8933fe..54c8ee28fcc4940517262389b16d4de1030709f3 100644 (file)
@@ -2898,6 +2898,8 @@ static void handle_stripe5(struct stripe_head *sh)
 
                for (i = conf->raid_disks; i--; ) {
                        set_bit(R5_Wantwrite, &sh->dev[i].flags);
+                       set_bit(R5_LOCKED, &dev->flags);
+                       s.locked++;
                        if (!test_and_set_bit(STRIPE_OP_IO, &sh->ops.pending))
                                sh->ops.count++;
                }
@@ -2911,6 +2913,7 @@ static void handle_stripe5(struct stripe_head *sh)
                        conf->raid_disks);
                s.locked += handle_write_operations5(sh, 1, 1);
        } else if (s.expanded &&
+                  s.locked == 0 &&
                !test_bit(STRIPE_OP_POSTXOR, &sh->ops.pending)) {
                clear_bit(STRIPE_EXPAND_READY, &sh->state);
                atomic_dec(&conf->reshape_stripes);