linux-kernel - Re: Simple script that locks up my box with recent kernels

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20061122080312.GL8055@kernel.dk>
Date:	Wed, 22 Nov 2006 09:03:13 +0100
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Linus Torvalds <torvalds@...l.org>
Cc:	Jesper Juhl <jesper.juhl@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>
Subject: Re: Simple script that locks up my box with recent kernels

On Tue, Nov 21 2006, Linus Torvalds wrote:
> I don't think we use any irq-disable locking in the VM itself, but I could 
> imagine some nasty situation with the block device layer getting into a 
> deadlock with interrupts disabled when it runs out of queue entries and 
> cannot allocate more memory..

Not likely. Request allocation is done with GFP_NOIO and backed by a
memory pool, so as long the vm doesn't go totally nuts because
__GFP_WAIT is set, we should be safe there. If it did go crazy, I
suspect a sysrq-t would still work.

If bouncing is involved for swap, we do have a potential deadlock issue
that isn't fixed yet. I just whipped up this completely untested patch,
it should shed some light on that issue.

diff --git a/mm/bounce.c b/mm/bounce.c
index e4b62d2..f75eb37 100644
--- a/mm/bounce.c
+++ b/mm/bounce.c
@@ -20,6 +20,7 @@ #define POOL_SIZE	64
 #define ISA_POOL_SIZE	16
 
 static mempool_t *page_pool, *isa_page_pool;
+static struct bio_set *bounce_bio_set;
 
 #ifdef CONFIG_HIGHMEM
 static __init int init_emergency_pool(void)
@@ -31,6 +32,9 @@ static __init int init_emergency_pool(vo
 	if (!i.totalhigh)
 		return 0;
 
+	bounce_bio_set = bioset_create(1, 1, 0);
+	BUG_ON(!bounce_bio_set);
+
 	page_pool = mempool_create_page_pool(POOL_SIZE, 0);
 	BUG_ON(!page_pool);
 	printk("highmem bounce pool size: %d pages\n", POOL_SIZE);
@@ -190,6 +194,11 @@ static int bounce_end_io_read_isa(struct
 	return 0;
 }
 
+static void bounce_bio_destructor(struct bio *bio)
+{
+	bio_free(bio, bounce_bio_set);
+}
+
 static void __blk_queue_bounce(request_queue_t *q, struct bio **bio_orig,
 			       mempool_t *pool)
 {
@@ -210,8 +219,10 @@ static void __blk_queue_bounce(request_q
 		/*
 		 * irk, bounce it
 		 */
-		if (!bio)
-			bio = bio_alloc(GFP_NOIO, (*bio_orig)->bi_vcnt);
+		if (!bio) {
+			bio = bio_alloc_bioset(GFP_NOIO, (*bio_orig)->bi_vcnt, bounce_bio_set);
+			bio->bi_destructor = bounce_bio_destructor;
+		}
 
 		to = bio->bi_io_vec + i;
 

-- 
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/