So you have.  See, the `dd' fills the machine up with dirty memory and the
loop driver wants to take a copy of all that memory to write it out.  It takes
this copy inside page reclaim, where we are allowed to use *all* memory.
So obviously, as there is so much memory to be written, we just run out of
the stuff.
The loop driver has a tendency to do this sort of thing.  Whenever it does,
we slap another bandaid on it.  
diff -puN drivers/block/loop.c~loop-hack drivers/block/loop.c
--- 25/drivers/block/loop.c~loop-hack	2003-02-24 21:21:11.000000000 -0800
+++ 25-akpm/drivers/block/loop.c	2003-02-24 21:45:13.000000000 -0800
@@ -447,7 +447,22 @@ static struct bio *loop_get_buffer(struc
 		goto out_bh;
 	}
 
-	bio = bio_copy(rbh, GFP_NOIO, rbh->bi_rw & WRITE);
+	/*
+	 * When called on the page reclaim -> writepage path, this code can
+	 * trivially consume all memory.  So we drop PF_MEMALLOC to avoid
+	 * stealing all the page reserves and throttle to the writeout rate.
+	 * pdflush will have been woken by page reclaim.  Let it do its work.
+	 */
+	do {
+		int flags = current->flags;
+
+		current->flags &= ~PF_MEMALLOC;
+		bio = bio_copy(rbh, (GFP_ATOMIC & ~__GFP_HIGH) | __GFP_NOWARN,
+					rbh->bi_rw & WRITE);
+		current->flags = flags;
+		if (bio == NULL)
+			blk_congestion_wait(WRITE, HZ/10);
+	} while (bio == NULL);
 
 	bio->bi_end_io = loop_end_io_transfer;
 	bio->bi_private = rbh;
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/