linux-kernel - Re: ZONE

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]

Date:	Thu, 21 Sep 2006 09:57:13 -0700
From:	Martin Bligh <mbligh@...igh.org>
To:	Christoph Lameter <clameter@....com>
Cc:	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org,
	Christoph Lameter <clameter@...r.sgi.com>
Subject: Re: ZONE_DMA

Christoph Lameter wrote:
> On Wed, 20 Sep 2006, Martin J. Bligh wrote:
> 
> 
>>>ZONE_DMA is only used as ZONE_NORMAL if the architecture does not need
>>>ZONE_NORMAL because all of memory is reachable via DMA.
>>
>>That's still inconsistent because it doesn't say DMA for *which*
>>device.
> 
> 
> Thats the way ZONE_DMA works right now and AFAIK the only way forward is 
> to make it optional and then introduce another way of allocating memory
> for a device. The migrate away from it. The first step is to allow people
> who do not need ZONE_DMA to opt out.

OK. Let's leave aside the issue for a second of whether ZONE_DMA should
be configurable or not (ie your patch), and just worry about how this
works in practice going forwards in the short term. Don't get me wrong,
I'd love to kill ZONE_DMA, or at least the 16MB way it's implemented in
i386 right now.

I presume the fallback order for everything is still
HIGHMEM -> NORMAL -> DMA, and nobody is proposing changing that.
(ignoring DMA32 to keep thing simpler).

If a device driver wants "DMAable" memory, and thus does a ZONE_DMA 
allocation, and we've moved all its memory from ZONE_DMA to ZONE_NORMAL
(as I think you're proposing doing for PPC64 (and ia64?)), then the
allocation will fail.

So are we saying that no driver code should be calling with GFP_DMA
(a quick grep turns up 148 instances under driver/), that if they do
they should only work on specific architectures (some instances were
s390-only drivers)? If so, should we not be removing the definiton of
GFP_DMA itself if ZONE_DMA is config'ed out, so that it fails at
compile time, rather than runtime?

>>AFAICS, the correct way to do this is have the requestor pass a memory
>>bound into the allocator, and have the arch figure out which zones
>>are applicable.
> 
> Exactly. But you cannot do that with ZONE_DMA __GFP_DMA. We likely need a 
> new page  allocator API for that.

Glad we're agreed on that, at least.

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