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]

Message-ID: <45131D2D.8020403@mbligh.org>
Date:	Thu, 21 Sep 2006 16:15:57 -0700
From:	Martin Bligh <mbligh@...igh.org>
To:	Christoph Lameter <clameter@....com>
Cc:	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org,
	Rohit Seth <rohitseth@...gle.com>
Subject: Re: ZONE_DMA

>>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.
> 
> I would not presume proposing anything for PPC64 and left everything the 
> way it is. The arch people can control if they want ZONE DMA or not and 
> the default is to leave things as is. If PPC64 wants to go ZONE_DMAless 
> then the arch code needs to be modified not refer to ZONE_DMA anymore and 
> if that works then we can switch CONFIG_ZONE_DMA off for PPC64. See the 
> patches in mm for examples how other arches have done it.

Sorry, there was some confusion then, maybe I misunderstood one of your
earlier emails.

>>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?
> 
> 
> This was covered at length before. Removing all GFP_DMA references would 
> require extensive #ifdefs. The limited patch in mm is only neutering 
> GFP_DMA for arches that do not need it. If an arch has removed its definition of 
> CONFIG_ZONE_DMA then __GFP_DMA will be ignored in the page allocator.

Just ignoring GFP_DMA in the allocator seems like a horrible violation
to me. GFP_DMA means "give me memory from ZONE_DMA". We're both well
aware that the whole concept of ZONE_DMA doesn't make much sense, but
still, that's what it does.

So if you just put all of memory in ZONE_DMA for your particular
machine, and bumped the DMA limit up to infinity, we wouldn't need
any of these patches, right? Which would also match what the other
arches do for this (eg PPC64).

Seems like a much simpler way of solving the problem to me. Or do you
think that won't work for some reason?

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/