linux-kernel - Re: [PATCH 1/2 v2] Driver for Freescale 8610 and 5121 DIU

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <20080324114740.337509d3.akpm@linux-foundation.org>
Date:	Mon, 24 Mar 2008 11:47:40 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Timur Tabi <timur@...escale.com>
Cc:	yorksun@...escale.com, linux-kernel@...r.kernel.org,
	linuxppc-dev@...abs.org, galak@...nel.crashing.org,
	linux-fbdev-devel@...ts.sourceforge.net, a.p.zijlstra@...llo.nl
Subject: Re: [PATCH 1/2 v2] Driver for Freescale 8610 and 5121 DIU

On Mon, 24 Mar 2008 09:53:16 -0500
Timur Tabi <timur@...escale.com> wrote:

> Andrew Morton wrote:
> 
> >>> GFP_DMA implies GFP_ATOMIC, but it's appropriate for documentation purposes.
> >> So does that mean that "GFP_DMA | GFP_KERNEL" is always wrong?
> > 
> > No, that's OK too.  It's just that GFP_DMA|GFP_ATOMIC is a bit redundant
> > and misleading.  GFP_DMA is already atomic; the only effect of adding
> > GFP_ATOMIC to GFP_DMA is to add __GFP_HIGH.
> > 
> > Don't wory about it ;)
> 
> Well, maybe we don't want GFP_ATOMIC then, because I don't think we want
> __GFP_HIGH.  Looking at the code, it appears the __GFP_HIGH has nothing to do
> with HIGHMEM (which on PowerPC is the not 1-to-1 mapping memory from 0xF000000
> to 0xFFFFFFFF).  Further examination of the cools shows the __GFP_HIGH says to
> try access the "emergency pool", and I see this code snippet:
> 
> 	if (alloc_flags & ALLOC_HIGH)
> 		min -= min / 2;
> 
> I guess this means that we reduce the amount of memory that can be available in
> order for the allocate to succeed.
> 
> Considering that the amount of memory that we allocate is in the order of
> megabytes, and it really isn't that important, I would think that we don't want
> to touch the emergency pool.  Does that sound right?

yup.  The absence of __GFP_WAIT already causes the page allocator to try a
bit harder.  Adding __GFP_HIGH would make it try harder still.

You do need to be sure that the driver will robustly and correctly recover
from an allocation failure here.

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