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: Thu, 6 Dec 2012 10:11:38 +1100	[thread overview]
Message-ID: <20121206101138.551a7dfa@notabene.brown> (raw)
In-Reply-To: <50BFC9AD.4060006@brockmann-consult.de>

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

On Wed, 05 Dec 2012 23:24:45 +0100 Peter Maloney
<peter.maloney@brockmann-consult.de> wrote:

> On 11/27/2012 02:19 AM, NeilBrown wrote:
> > 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.
> >> [...]
> >> # 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;
> 
> 
> It works; copying my LV no longer hangs. Thanks. :)
> 
> $ uname -a
> Linux peter 3.7.0-rc7-1-default+ #3 SMP Wed Dec 5 22:20:58 CET 2012
> x86_64 x86_64 x86_64 GNU/Linux
> 

Great!  Thanks for the confirmation.

NeilBrown


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

      reply	other threads:[~2012-12-05 23:11 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
2012-12-05 22:24   ` Peter Maloney
2012-12-05 23:11     ` NeilBrown [this message]

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=20121206101138.551a7dfa@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).