[PATCH] block: blk_queue_bounce_limits can actually sleep

[PATCH] block: blk_queue_bounce_limits can actually sleep

[Arjan van de Ven]

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

Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
---
 block/blk-settings.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/block/blk-settings.c b/block/blk-settings.c
index 8dd8641..c420a67 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -148,6 +148,7 @@ void blk_queue_bounce_limit(struct request_queue *q, u64 dma_addr)
 	q->bounce_pfn = b_pfn;
 #endif
 	if (dma) {
+		might_sleep();
 		init_emergency_isa_pool();
 		q->bounce_gfp = GFP_NOIO | GFP_DMA;
 		q->bounce_pfn = b_pfn;
-- 
1.5.4.5

Re: [PATCH] block: blk_queue_bounce_limits can actually sleep

[Jens Axboe]

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?

-- 
Jens Axboe

Re: [PATCH] block: blk_queue_bounce_limits can actually sleep

[Andrew Morton]

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.
_

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

Re: [PATCH] block: blk_queue_bounce_limits can actually sleep

[Jens Axboe]

On Tue, May 20 2008, Andrew Morton wrote:
> 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).

> 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

Re: [PATCH] block: blk_queue_bounce_limits can actually sleep

[Arjan van de Ven]

On Tue, 20 May 2008 21:58:57 +0200
> Yeah, THAT I agree with in genereal, 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).
> 
> > 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 :-(
> 

well either it sleeps or it doesn't.....
if this guy should sleep (and right now it does) we shouldn't call it
from such contexts.
If we do the right thing and allocate the isa pools in a sane context,
it wouldn't ever sleep and the patch isn't needed...

Re: [PATCH] block: blk_queue_bounce_limits can actually sleep

[Arjan van de Ven]

On Tue, 20 May 2008 12:45:56 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:

> 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.
> _
> 
> but it's all vague and waffly because Arjan forgot to tell us why he's
> bothering to patch this code at all???

the sata_nv driver calls this from an invalid context ... and spews a
ton of warnings as a result... made me think this is a common mistake
to make.

I'd love to make it do your version instead, but I was afraid it would
trigger too often....