linux-kernel - Re: [PATCH] Make GFP_DMA allocations w/o 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] [day] [month] [year] [list]

Date:	Sun, 12 Jun 2011 14:48:09 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Robert Hancock <hancockrwd@...il.com>
Cc:	Catalin Marinas <catalin.marinas@....com>,
	David Rientjes <rientjes@...gle.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	tglx@...utronix.de, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, mel@....ul.ie,
	kamezawa.hiroyu@...fujitsu.com, riel@...hat.com, pavel@....cz
Subject: Re: [PATCH] Make GFP_DMA allocations w/o ZONE_DMA emit a warning
	instead of failing

On Sat, Jun 11, 2011 at 11:18:46AM -0600, Robert Hancock wrote:
> It sounds to me like these drivers using GFP_DMA should really be fixed  
> to use the proper DMA API. That's what it's there for. The problem is  
> that GFP_DMA doesn't really mean anything generically other than "memory  
> suitable for DMA according to some criteria".

It would be really nice to have an allocation interface which takes a
DMA mask and returns memory which satisfies that DMA mask, but that's
a pipedream I've had for the last 12 years or so.

GFP_DMA is not about the DMA API - the DMA API does _not_ deal with
memory allocation for streaming transfers at all.  It only deals with
coherent DMA memory allocation which is something completely different.

So it really isn't about "these drivers should be fixed to use the
proper DMA API" because there isn't one.

If the concensus is to remove GFP_DMA, there would need to be some ground
work done first:

(a) audit whether GFP_DMA is really needed (iow, is the allocated
structure actually DMA'd from/to, or did the driver writer just slap
GFP_DMA on it without thinking?)

(b) audit whether we have a DMA mask available at the GFP_DMA allocator
call site

That should reveal whether it is even possible to move to a different
solution.

Depending on (b), provide a new allocation API which takes the DMA mask
and internally calls the standard allocator with GFP_DMA if the DMA mask
is anything less than "all memory".
--
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/