md/raid1: consider WRITE as successful only if at least one non-Faulty and non-rebuil...
authorAlex Lyakas <alex@zadarastorage.com>
Tue, 4 Jun 2013 17:42:21 +0000 (20:42 +0300)
committerBen Hutchings <ben@decadent.org.uk>
Wed, 19 Jun 2013 01:17:02 +0000 (02:17 +0100)
commit58e06b1d5e77f6cbed3cddc39e7d782d462e1883
tree0d0b4bf00a0aaa1a8f41a2c47111f2ae0d78e370
parentc161265b6435d331954ffe056559dfda7f9f7ba1
md/raid1: consider WRITE as successful only if at least one non-Faulty and non-rebuilding drive completed it.

commit 3056e3aec8d8ba61a0710fb78b2d562600aa2ea7 upstream.

Without that fix, the following scenario could happen:

- RAID1 with drives A and B; drive B was freshly-added and is rebuilding
- Drive A fails
- WRITE request arrives to the array. It is failed by drive A, so
r1_bio is marked as R1BIO_WriteError, but the rebuilding drive B
succeeds in writing it, so the same r1_bio is marked as
R1BIO_Uptodate.
- r1_bio arrives to handle_write_finished, badblocks are disabled,
md_error()->error() does nothing because we don't fail the last drive
of raid1
- raid_end_bio_io()  calls call_bio_endio()
- As a result, in call_bio_endio():
        if (!test_bit(R1BIO_Uptodate, &r1_bio->state))
                clear_bit(BIO_UPTODATE, &bio->bi_flags);
this code doesn't clear the BIO_UPTODATE flag, and the whole master
WRITE succeeds, back to the upper layer.

So we returned success to the upper layer, even though we had written
the data onto the rebuilding drive only. But when we want to read the
data back, we would not read from the rebuilding drive, so this data
is lost.

[neilb - applied identical change to raid10 as well]

This bug can result in lost data, so it is suitable for any
-stable kernel.

Signed-off-by: Alex Lyakas <alex@zadarastorage.com>
Signed-off-by: NeilBrown <neilb@suse.de>
[bwh: Backported to 3.2: for raid10, s/rdev/conf->mirrors[dev].rdev/]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
drivers/md/raid1.c
drivers/md/raid10.c