summaryrefslogtreecommitdiffstats
path: root/drivers
diff options
context:
space:
mode:
authorShaohua Li <shli@fb.com>2015-09-04 23:14:16 +0200
committerNeilBrown <neilb@suse.com>2015-11-01 03:48:27 +0100
commit253f9fd41afe2492b85de779946b5882a00dcdc5 (patch)
treeb8861ac9970c0306dd05cb3fe0242ce953d79f4e /drivers
parentraid5-cache: check stripe finish out of order (diff)
downloadlinux-253f9fd41afe2492b85de779946b5882a00dcdc5.tar.xz
linux-253f9fd41afe2492b85de779946b5882a00dcdc5.zip
raid5-cache: don't delay stripe captured in log
There is a case a stripe gets delayed forever. 1. a stripe finishes construction 2. a new bio hits the stripe 3. handle_stripe runs for the stripe. The stripe gets DELAYED bit set since construction can't run for new bio (the stripe is locked since step 1) Without log, handle_stripe will call ops_run_io. After IO finishes, the stripe gets unlocked and the stripe will restart and run construction for the new bio. With log, ops_run_io need to run two times. If the DELAYED bit set, the stripe can't enter into the handle_list, so the second ops_run_io doesn't run, which leaves the stripe stalled. Signed-off-by: Shaohua Li <shli@fb.com> Signed-off-by: NeilBrown <neilb@suse.com>
Diffstat (limited to 'drivers')
-rw-r--r--drivers/md/raid5-cache.c5
1 files changed, 5 insertions, 0 deletions
diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
index 30c7e5e79a02..0460882a5fd7 100644
--- a/drivers/md/raid5-cache.c
+++ b/drivers/md/raid5-cache.c
@@ -479,6 +479,11 @@ int r5l_write_stripe(struct r5l_log *log, struct stripe_head *sh)
return -EINVAL;
set_bit(STRIPE_LOG_TRAPPED, &sh->state);
+ /*
+ * The stripe must enter state machine again to finish the write, so
+ * don't delay.
+ */
+ clear_bit(STRIPE_DELAYED, &sh->state);
atomic_inc(&sh->count);
mutex_lock(&log->io_mutex);