linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Peter Maloney <peter.maloney@brockmann-consult.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: 3.7-rc4 hang with mdadm raid10 near layout, with 4 disks, and an internal bitmap
Date: Tue, 27 Nov 2012 12:19:14 +1100	[thread overview]
Message-ID: <20121127121914.77f6111e@notabene.brown> (raw)
In-Reply-To: <50A28D53.2080409@brockmann-consult.de>

[-- Attachment #1: Type: text/plain, Size: 3022 bytes --]

On Tue, 13 Nov 2012 19:11:31 +0100 Peter Maloney
<peter.maloney@brockmann-consult.de> wrote:

> I am using kernel 3.7-rc4. I have 2 LV on a 4 disk raid10 near layout
> mdadm device which I am trying to copy to another LV on the same VG
> using dd. The mdadm device has an internal bitmap. When I copy the first
> LV, it goes smoothly, but with the 2nd it hangs before it is done.
> 
> I don't know if I can reproduce it, so I'll just leave it broken with a
> bitmap until this is resolved, and work around by using files for what
> I'm trying to do right now. It's my home desktop machine.
> 
> Should I start by installing 3.6.6 or 3.7.0-rc5?
> 
> When I created my raid, I was probably using kernel 3.1 or 3.4.4. When I
> added the bitmap, it was probably 3.7-rc2.
> 
> # uname -a
> Linux peter 3.7.0-rc4-1-default #7 SMP Sun Nov 4 23:11:57 CET 2012
> x86_64 x86_64 x86_64 GNU/Linux
> 

....


Thanks for the report.
Should be fixed by the following.

NeilBrown

Author: NeilBrown <neilb@suse.de>
Date:   Tue Nov 27 12:14:40 2012 +1100

    md/raid1{,0}: fix deadlock in bitmap_unplug.
    
    If the raid1 or raid10 unplug function gets called
    from a make_request function (which is very possible) when
    there are bios on the current->bio_list list, then it will not
    be able to successfully call bitmap_unplug() and it could
    need to submit more bios and wait for them to complete.
    But they won't complete while current->bio_list is non-empty.
    
    So detect that case and handle the unplugging off to another thread
    just like we already do when called from within the scheduler.
    
    RAID1 version of bug was introduced in 3.6, so that part of fix is
    suitable for 3.6.y.  RAID10 part won't apply.
    
    Cc: stable@vger.kernel.org
    Reported-by: Torsten Kaiser <just.for.lkml@googlemail.com>
    Reported-by: Peter Maloney <peter.maloney@brockmann-consult.de>
    Signed-off-by: NeilBrown <neilb@suse.de>

diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index 636bae0..a0f7309 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -963,7 +963,7 @@ static void raid1_unplug(struct blk_plug_cb *cb, bool from_schedule)
 	struct r1conf *conf = mddev->private;
 	struct bio *bio;
 
-	if (from_schedule) {
+	if (from_schedule || current->bio_list) {
 		spin_lock_irq(&conf->device_lock);
 		bio_list_merge(&conf->pending_bio_list, &plug->pending);
 		conf->pending_count += plug->pending_cnt;
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index 0d5d0ff..c9acbd7 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -1069,7 +1069,7 @@ static void raid10_unplug(struct blk_plug_cb *cb, bool from_schedule)
 	struct r10conf *conf = mddev->private;
 	struct bio *bio;
 
-	if (from_schedule) {
+	if (from_schedule || current->bio_list) {
 		spin_lock_irq(&conf->device_lock);
 		bio_list_merge(&conf->pending_bio_list, &plug->pending);
 		conf->pending_count += plug->pending_cnt;

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

  reply	other threads:[~2012-11-27  1:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-13 18:11 3.7-rc4 hang with mdadm raid10 near layout, with 4 disks, and an internal bitmap Peter Maloney
2012-11-27  1:19 ` NeilBrown [this message]
2012-12-05 22:24   ` Peter Maloney
2012-12-05 23:11     ` 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=20121127121914.77f6111e@notabene.brown \
    --to=neilb@suse.de \
    --cc=linux-raid@vger.kernel.org \
    --cc=peter.maloney@brockmann-consult.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 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).