On Tue, May 20 2008, Andrew Morton wrote:
quoted text
> On Tue, 20 May 2008 21:29:59 +0200
> Jens Axboe <jens.axboe@oracle.com> wrote:
> 
> > On Mon, May 19 2008, Arjan van de Ven wrote:
> > > From: Arjan van de Ven <arjan@linux.intel.com>
> > > 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:
> 
> foo()
> {
> 	...
> 	if (some_unlikely_condition())
> 		do_something_which_sleeps();
> 	...
> }
> 
> 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.

Yeah, THAT I agree with in general, but it's probably too much here
since most callers will not block and probably do call it under the
queue lock already (just guessing here, didn't audit any callers).

quoted text
> but it's all vague and waffly because Arjan forgot to tell us why he's
> bothering to patch this code at all???

Probably the math still isn't quite correct, so it ends up setting up
the isa pool for no good reason :-(

-- 
Jens Axboe

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