All of lore.kernel.org
 help / color / mirror / Atom feed
From: "K.Tanaka" <k-tanaka@ce.jp.nec.com>
To: Neil Brown <neilb@suse.de>
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-raid@vger.kernel.org, dm-devel@redhat.com
Subject: Re: [BUG] The kernel thread for md RAID1 could cause a md RAID1 array deadlock
Date: Thu, 24 Jan 2008 18:32:39 +0900	[thread overview]
Message-ID: <47985B37.9000503@ce.jp.nec.com> (raw)
In-Reply-To: <18328.1473.26122.647283@notabene.brown>

Hi,

Thank you for the patch.
I have applied the patch to 2.6.23.14 and it works well.

- In case of 2.6.23.14, the problem is reproduced.
- In case of 2.6.23.14 with this patch, raid1 works well so far.
  The fault injection script continues to run, and it doesn't deadlock.
  I will keep it running for a while.

Also, md raid10 seems to have the same problem.
I will test raid10 applying this patch as well.


Neil Brown wrote:
> On Tuesday January 15, k-tanaka@ce.jp.nec.com wrote:
>> This message describes the details about md-RAID1 issue found by
>> testing the md RAID1 using the SCSI fault injection framework.
>>
>> Abstract:
>> Both the error handler for md RAID1 and write access request to the md RAID1
>> use raid1d kernel thread. The nr_pending flag could cause a race condition
>> in raid1d, results in a raid1d deadlock.
> 
> Thanks for finding and reporting this.
> 
> I believe the following patch should fix the deadlock.
> 
> If you are able to repeat your test and confirm this I would
> appreciate it.
> 
> Thanks,
> NeilBrown
> 
> 
> 
> Fix deadlock in md/raid1 when handling a read error.
> 
> When handling a read error, we freeze the array to stop any other
> IO while attempting to over-write with correct data.
> 
> This is done in the raid1d thread and must wait for all submitted IO
> to complete (except for requests that failed and are sitting in the
> retry queue - these are counted in ->nr_queue and will stay there during
> a freeze).
> 
> However write requests need attention from raid1d as bitmap updates
> might be required.  This can cause a deadlock as raid1 is waiting for
> requests to finish that themselves need attention from raid1d.
> 
> So we create a new function 'flush_pending_writes' to give that attention,
> and call it in freeze_array to be sure that we aren't waiting on raid1d.
> 
> Thanks to "K.Tanaka" <k-tanaka@ce.jp.nec.com> for finding and reporting
> this problem.
> 
> Cc: "K.Tanaka" <k-tanaka@ce.jp.nec.com>
> Signed-off-by: Neil Brown <neilb@suse.de>
> 
-- 
---------------------------------------------------------
Kenichi TANAKA    | Open Source Software Platform Development Division
                  | Computers Software Operations Unit, NEC Corporation
                  | k-tanaka@ce.jp.nec.com

  reply	other threads:[~2008-01-24  9:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-15  3:10 [BUG] The kernel thread for md RAID1 could cause a md RAID1 array deadlock K.Tanaka
2008-01-24  3:28 ` Neil Brown
2008-01-24  9:32   ` K.Tanaka [this message]
2008-01-30  2:02     ` K.Tanaka

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=47985B37.9000503@ce.jp.nec.com \
    --to=k-tanaka@ce.jp.nec.com \
    --cc=dm-devel@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=linux-scsi@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.