linux-kernel - Re: [PATCH] block: blk_queue_bounce

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 20 May 2008 21:58:57 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	arjan@...radead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] block: blk_queue_bounce_limits can actually sleep

On Tue, May 20 2008, Andrew Morton wrote:
> On Tue, 20 May 2008 21:29:59 +0200
> Jens Axboe <jens.axboe@...cle.com> wrote:
> 
> > On Mon, May 19 2008, Arjan van de Ven wrote:
> > > From: Arjan van de Ven <arjan@...ux.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

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