summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorNeilBrown <neilb@suse.de>2012-11-22 05:12:09 +0100
committerNeilBrown <neilb@suse.de>2012-11-22 05:12:42 +0100
commit884162df2aadd7414bef4935e1a54976fd4e3988 (patch)
treee562edba9a947346b124e9583de9d20f41c7f8c5
parentmd/raid10: close race that lose writes lost when replacement completes. (diff)
downloadlinux-884162df2aadd7414bef4935e1a54976fd4e3988.tar.xz
linux-884162df2aadd7414bef4935e1a54976fd4e3988.zip
md/raid10: decrement correct pending counter when writing to replacement.
When a write to a replacement device completes, we carefully and correctly found the rdev that the write actually went to and the blithely called rdev_dec_pending on the primary rdev, even if this write was to the replacement. This means that any writes to an array while a replacement was ongoing would cause the nr_pending count for the primary device to go negative, so it could never be removed. This bug has been present since replacement was introduced in 3.3, so it is suitable for any -stable kernel since then. Reported-by: "George Spelvin" <linux@horizon.com> Cc: stable@vger.kernel.org Signed-off-by: NeilBrown <neilb@suse.de>
-rw-r--r--drivers/md/raid10.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index ad032518fdc0..0d5d0ff2c0f7 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -499,7 +499,7 @@ static void raid10_end_write_request(struct bio *bio, int error)
*/
one_write_done(r10_bio);
if (dec_rdev)
- rdev_dec_pending(conf->mirrors[dev].rdev, conf->mddev);
+ rdev_dec_pending(rdev, conf->mddev);
}
/*