From: Jes Sorensen <jes@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [PATCH 3/6] Optional ZONE_DMA in the VM
Date: Tue, 12 Sep 2006 08:30:11 +0000 [thread overview]
Message-ID: <yq0r6yhfpws.fsf@jaguar.mkp.net> (raw)
In-Reply-To: <20060911222744.4849.26386.sendpatchset@schroedinger.engr.sgi.com>
>>>>> "Nick" = Nick Piggin <nickpiggin@yahoo.com.au> writes:
Nick> Christoph Lameter wrote:
>> On Tue, 12 Sep 2006, Nick Piggin wrote:
>>> I can't see from your patches, but what happens if someone asks
>>> for a GFP_DMA page or dma slab allocation when there is no
>>> ZONE_DMA?
>>>
>> The page/slab allocator will simply ignore the flag and return
>> ZONE_NORMAL memory. See gfp_zone().
Nick> That's wrong, I think? It should return NULL surely? (and
Nick> possibly do a printk telling the user they should enable
Nick> ZONE_DMA config, although some users have valid fallback
Nick> strategies).
That was what hit my mind first as well when I saw these patches. The
other issue is what about 64 bit machines that are trying to allocate
32 bit addresses because they are either out of IOMMU slots or needs
to allocate bounce buffers for swiotlb support? Silently trying to
feed a device a 64 bit address could have some 'interesting' side
effects.
So I totally agree, GFP_DMA allocations really ought to fail in this
situation and we should fixup the users instead.
Cheers,
Jes
next prev parent reply other threads:[~2006-09-12 8:30 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20060918183614.19679.50359.sendpatchset@schroedinger.engr.sgi.com>
2006-09-11 22:27 ` [PATCH 0/8] Optional ZONE_DMA V1 Christoph Lameter
2006-09-11 22:27 ` [PATCH 2/6] Introduce CONFIG_ZONE_DMA Christoph Lameter
2006-09-18 13:55 ` Christoph Hellwig
2006-09-18 14:08 ` Martin Schwidefsky
2006-09-18 17:28 ` Christoph Lameter
2006-09-19 8:03 ` Martin Schwidefsky
2006-09-18 14:42 ` Russell King
2006-09-18 14:58 ` James Bottomley
2006-09-18 17:30 ` Christoph Lameter
2006-09-18 15:22 ` Paul Mundt
2006-09-18 17:33 ` Christoph Lameter
2006-09-18 22:45 ` Paul Mundt
2006-09-18 22:58 ` Christoph Lameter
2006-09-18 23:25 ` Paul Mundt
2006-09-11 22:27 ` [PATCH 3/6] Optional ZONE_DMA in the VM Christoph Lameter
2006-09-12 0:35 ` Nick Piggin
2006-09-12 1:40 ` Christoph Lameter
2006-09-12 2:40 ` Nick Piggin
2006-09-12 7:22 ` Andi Kleen
2006-09-12 8:30 ` Jes Sorensen [this message]
2006-09-12 9:12 ` Jes Sorensen
2006-09-12 18:05 ` Christoph Lameter
2006-09-12 7:30 ` [PATCH 0/8] Optional ZONE_DMA V1 Arjan van de Ven
2006-09-12 13:34 ` Jack Steiner
2006-09-12 17:25 ` Christoph Lameter
2006-09-12 17:33 ` Christoph Lameter
2006-09-12 17:47 ` Martin Bligh
2006-09-12 17:53 ` Christoph Lameter
2006-09-12 17:40 ` Martin Bligh
2006-09-13 2:41 ` Nick Piggin
2006-09-13 7:55 ` Jes Sorensen
2006-09-13 7:57 ` Jes Sorensen
2006-09-13 8:10 ` Christoph Lameter
2006-09-13 9:52 ` Jes Sorensen
2006-09-13 17:23 ` Christoph Lameter
2006-09-13 17:49 ` Jack Steiner
2006-09-13 18:00 ` Christoph Lameter
2006-09-14 8:52 ` Jes Sorensen
2006-09-14 16:55 ` Christoph Lameter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=yq0r6yhfpws.fsf@jaguar.mkp.net \
--to=jes@sgi.com \
--cc=linux-ia64@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox