From: Neil Brown <neilb@suse.de>
To: Shaohua Li <shli@fb.com>
Cc: linux-raid@vger.kernel.org, Kernel-team@fb.com,
songliubraving@fb.com, hch@infradead.org,
dan.j.williams@intel.com
Subject: Re: [PATCH 2/2] raid5: update analysis state for failed stripe
Date: Thu, 24 Sep 2015 15:26:57 +1000 [thread overview]
Message-ID: <87d1x8wfoe.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <20150923063425.GA2813864@devbig084.prn1.facebook.com>
[-- Attachment #1: Type: text/plain, Size: 3758 bytes --]
Shaohua Li <shli@fb.com> writes:
> On Wed, Sep 23, 2015 at 04:21:58PM +1000, Neil Brown wrote:
>> Shaohua Li <shli@fb.com> writes:
>>
>> > handle_failed_stripe() makes the stripe fail, eg, all IO will return
>> > with a failure, but it doesn't update stripe_head_state. Later
>> > handle_stripe() has special handling for raid6 for handle_stripe_fill().
>> > That check before handle_stripe_fill() doesn't skip the failed stripe
>> > and we get a kernel crash in need_this_block. This patch clear the
>> > analysis state to make sure no functions wrongly called after
>> > handle_failed_stripe()
>> >
>> > Signed-off-by: Shaohua Li <shli@fb.com>
>> > ---
>> > drivers/md/raid5.c | 4 ++++
>> > 1 file changed, 4 insertions(+)
>> >
>> > diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
>> > index 394cdf8..8e4fb89a 100644
>> > --- a/drivers/md/raid5.c
>> > +++ b/drivers/md/raid5.c
>> > @@ -3155,6 +3155,8 @@ handle_failed_stripe(struct r5conf *conf, struct stripe_head *sh,
>> > spin_unlock_irq(&sh->stripe_lock);
>> > if (test_and_clear_bit(R5_Overlap, &sh->dev[i].flags))
>> > wake_up(&conf->wait_for_overlap);
>> > + if (bi)
>> > + s->to_read--;
>> > while (bi && bi->bi_iter.bi_sector <
>> > sh->dev[i].sector + STRIPE_SECTORS) {
>> > struct bio *nextbi =
>> > @@ -3173,6 +3175,8 @@ handle_failed_stripe(struct r5conf *conf, struct stripe_head *sh,
>> > */
>> > clear_bit(R5_LOCKED, &sh->dev[i].flags);
>> > }
>> > + s->to_write = 0;
>> > + s->written = 0;
>> >
>> > if (test_and_clear_bit(STRIPE_FULL_WRITE, &sh->state))
>> > if (atomic_dec_and_test(&conf->pending_full_writes))
>> > --
>> > 1.8.1
>>
>> Again, this probably is a sensible fix, but I would like to be certain.
>> Where exactly in need_this_block does the kernel crash? I cannot see
>> anything that could cause an invalid address....
>
>
>>>for (i = 0; i < s->failed; i++) {
>>> if (fdev[i]->towrite &&
> the fdev[i]->towrite. because s->failed >=2 (it's 3 in my case), while
> the array size is 2.
>
> Thanks,
> Shaohua
Ahh, of course.
In that case I think I'd like to limit the for loop as well.
So I've applied your patch and this one as well.
Thanks,
NeilBrown
From 76e308d70b204ff0af0028458caabfeacac4541a Mon Sep 17 00:00:00 2001
From: NeilBrown <neilb@suse.com>
Date: Thu, 24 Sep 2015 15:25:36 +1000
Subject: [PATCH] md/raid5: don't index beyond end of array in
need_this_block().
When need_this_block probably shouldn't be called when there
are more than 2 failed devices, we really don't want it to try
indexing beyond the end of the failed_num[] of fdev[] arrays.
So limit the loops to at most 2 iterations.
Reported-by: Shaohua Li <shli@fb.com>
Signed-off-by: NeilBrown <neilb@suse.de>
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 903d8a2b7b07..0f49ce411c9a 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -3304,7 +3304,7 @@ static int need_this_block(struct stripe_head *sh, struct stripe_head_state *s,
*/
return 0;
- for (i = 0; i < s->failed; i++) {
+ for (i = 0; i < s->failed && i < 2; i++) {
if (fdev[i]->towrite &&
!test_bit(R5_UPTODATE, &fdev[i]->flags) &&
!test_bit(R5_OVERWRITE, &fdev[i]->flags))
@@ -3328,7 +3328,7 @@ static int need_this_block(struct stripe_head *sh, struct stripe_head_state *s,
sh->sector < sh->raid_conf->mddev->recovery_cp)
/* reconstruct-write isn't being forced */
return 0;
- for (i = 0; i < s->failed; i++) {
+ for (i = 0; i < s->failed && i < 2; i++) {
if (s->failed_num[i] != sh->pd_idx &&
s->failed_num[i] != sh->qd_idx &&
!test_bit(R5_UPTODATE, &fdev[i]->flags) &&
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
next prev parent reply other threads:[~2015-09-24 5:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-18 17:20 [PATCH 1/2] md: clear CHANGE_PENDING in readonly array Shaohua Li
2015-09-18 17:20 ` [PATCH 2/2] raid5: update analysis state for failed stripe Shaohua Li
2015-09-23 6:21 ` Neil Brown
2015-09-23 6:34 ` Shaohua Li
2015-09-24 5:26 ` Neil Brown [this message]
2015-09-23 6:05 ` [PATCH 1/2] md: clear CHANGE_PENDING in readonly array Neil Brown
2015-09-23 6:23 ` Shaohua Li
2015-09-24 4:03 ` Neil Brown
2015-09-24 16:47 ` Shaohua Li
2015-09-30 6:59 ` Neil Brown
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=87d1x8wfoe.fsf@notabene.neil.brown.name \
--to=neilb@suse.de \
--cc=Kernel-team@fb.com \
--cc=dan.j.williams@intel.com \
--cc=hch@infradead.org \
--cc=linux-raid@vger.kernel.org \
--cc=shli@fb.com \
--cc=songliubraving@fb.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).