From: "Jianpeng Ma" <majianpeng@gmail.com>
To: Neil Brown <neilb@suse.de>
Cc: linux-raid <linux-raid@vger.kernel.org>
Subject: [PATCH 3/3] raid5: Fix to_read/to_write judgement.
Date: Sat, 22 Sep 2012 10:22:58 +0800 [thread overview]
Message-ID: <201209221022560932318@gmail.com> (raw)
In func analyse_stripe, it added to_read/to_write by
sh->dev[i]->toread/towrite.
If stripe failed, in func handle_failed_stripe it decreased
to_read/to_write also by sh->dev[i]->toread/towrite.
But between func analyse_stripe and handle_failed_stripe, toread/towrite
can change.So the to_read/to_write maybe less zero.
For example, if to_write was less zero,it may introduce a bug in func async_xor:
'BUG_ON(src_cnt <= 1);'.
So after handle_failed_stripe,it should use 'to_read/to_write > 0' instead
of judging 'to_read/to_write'.
Signed-off-by: Jianpeng Ma <majianpeng@gmail.com>
---
drivers/md/raid5.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index a56aa5b..554ca9e 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -2641,7 +2641,7 @@ static int fetch_block(struct stripe_head *sh, struct stripe_head_state *s,
(s->failed >= 2 && fdev[1]->toread) ||
(sh->raid_conf->level <= 5 && s->failed && fdev[0]->towrite &&
!test_bit(R5_OVERWRITE, &fdev[0]->flags)) ||
- (sh->raid_conf->level == 6 && s->failed && s->to_write))) {
+ (sh->raid_conf->level == 6 && s->failed && s->to_write > 0))) {
/* we would like to get this block, possibly by computing it,
* otherwise read it if the backing disk is insync
*/
@@ -3471,8 +3471,8 @@ static void handle_stripe(struct stripe_head *sh)
* parity, or to satisfy requests
* or to load a block that is being partially written.
*/
- if (s.to_read || s.non_overwrite
- || (conf->level == 6 && s.to_write && s.failed)
+ if (s.to_read > 0 || s.non_overwrite
+ || (conf->level == 6 && s.to_write > 0 && s.failed)
|| (s.syncing && (s.uptodate + s.compute < disks))
|| s.replacing
|| s.expanding)
@@ -3519,7 +3519,7 @@ static void handle_stripe(struct stripe_head *sh)
* 2/ A 'check' operation is in flight, as it may clobber the parity
* block.
*/
- if (s.to_write && !sh->reconstruct_state && !sh->check_state)
+ if (s.to_write > 0 && !sh->reconstruct_state && !sh->check_state)
handle_stripe_dirtying(conf, sh, &s, disks);
/* maybe we need to check and possibly fix the parity for this stripe
--
1.7.9.5
next reply other threads:[~2012-09-22 2:22 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-22 2:22 Jianpeng Ma [this message]
2012-09-25 7:12 ` [PATCH 3/3] raid5: Fix to_read/to_write judgement NeilBrown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201209221022560932318@gmail.com \
--to=majianpeng@gmail.com \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.