Re: [PATCH] block: blk_queue_bounce_limits can actually sleep

From: Andrew Morton
Date: Tue May 20 2008 - 15:46:49 EST

On Tue, 20 May 2008 21:29:59 +0200
Jens Axboe <jens.axboe@xxxxxxxxxx> wrote:

> On Mon, May 19 2008, Arjan van de Ven wrote:
> > From: Arjan van de Ven <arjan@xxxxxxxxxxxxxxx>
> > Subject: [PATCH] block: blk_queue_bounce_limits can actually sleep
> >
> > blk_queue_bounce_limit can call init_emergency_isa_pool, which
> > does sleeping allocations... document it as such by adding
> > might_sleep() to the driver
> Isn't that superflous, as mempool_create() -> kmalloc(..., __GFP_WAIT)
> ends up spewing that warning anyway?

It's largely superfluous given the way in which Arjan implemented it.

One situation which we regularly hit is:

if (some_unlikely_condition())

and then we go and call that code under spinlock and ship it out, when
of course a handful of testers hit the unlikely condition.

The solution to that is to add a might_sleep() _outside_ the test of
some_unlikely_condition(). ie:

--- a/block/blk-settings.c~a
+++ a/block/blk-settings.c
@@ -140,6 +140,8 @@ void blk_queue_bounce_limit(struct reque
unsigned long b_pfn = dma_addr >> PAGE_SHIFT;
int dma = 0;

+ might_sleep();
q->bounce_gfp = GFP_NOIO;
#if BITS_PER_LONG == 64
/* Assume anything <= 4GB can be handled by IOMMU.

but it's all vague and waffly because Arjan forgot to tell us why he's
bothering to patch this code at all???
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at