lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20070109121501.GJ11203@kernel.dk>
Date:	Tue, 9 Jan 2007 13:15:03 +0100
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Torsten Kaiser <kernel@...dioc.dyndns.org>,
	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org
Subject: Re: [BUG 2.6.20-rc3-mm1] raid1 mount blocks for ever

On Tue, Jan 09 2007, Fengguang Wu wrote:
> On Tue, Jan 09, 2007 at 10:19:00AM +0100, Jens Axboe wrote:
> > On Mon, Jan 08 2007, Torsten Kaiser wrote:
> > > On Monday 08 January 2007 09:52, Jens Axboe wrote:
> > > > --- a/block/ll_rw_blk.c
> > > > +++ b/block/ll_rw_blk.c
> > > > @@ -1542,7 +1542,7 @@ static inline void
> > > > -	blk_unplug_current();
> > > > +	blk_replug_current_nested();
> > > 
> > > Does not help. Dmesg follows:
> > 
> > [snip]
> > 
> > Strange, it works perfectly for me now. Not using -mm though, but the
> > plug branch. And it did hang before. Fengguang, any change for you?
> 
> 2.6.20-rc3-mm1 plus your patch works for me.
> 
> Lucky enough to found this before giving up:
> 
>         mount takes 39s, and umount takes 42s.

Do the finish quicker, if you cat /proc/mdstat after issuing the mount
or umount? I'm testing md right now and I'm seeing a few oddities wrt
that, looking further...

You probably also want this, at least if you ever shut down your arrays.

diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c
index 4c8ac7e..34b7936 100644
--- a/block/ll_rw_blk.c
+++ b/block/ll_rw_blk.c
@@ -1745,6 +1745,11 @@ request_queue_t *blk_alloc_queue_node(gf
 
 	memset(q, 0, sizeof(*q));
 
+	if (init_qrcu_struct(&q->qrcu)) {
+		kmem_cache_free(requestq_cachep, q);
+		return NULL;
+	}
+
 	snprintf(q->kobj.name, KOBJ_NAME_LEN, "%s", "queue");
 	q->kobj.ktype = &queue_ktype;
 	kobject_init(&q->kobj);
@@ -1802,11 +1807,6 @@ blk_init_queue_node(request_fn_proc *rfn
 	if (!q)
 		return NULL;
 
-	if (init_qrcu_struct(&q->qrcu)) {
-		kmem_cache_free(requestq_cachep, q);
-		return NULL;
-	}
-
 	q->node = node_id;
 	if (blk_init_free_list(q)) {
 		cleanup_qrcu_struct(&q->qrcu);

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ