Date: Thu, 09 Nov 2006 19:01:43 -0800 (PST)
Message-Id: <20061109.190143.78711283.davem@davemloft.net>
To: benh@kernel.crashing.org
Cc: linux-input@atrey.karlin.mff.cuni.cz, linux-kernel@vger.kernel.org,
       paulus@samba.org, anton@samba.org, greg@kroah.com
Subject: Re: DMA APIs gumble grumble
From: David Miller <davem@davemloft.net>
In-Reply-To: <1163127327.4982.79.camel@localhost.localdomain>
References: <1163120524.4982.61.camel@localhost.localdomain>
	<20061109.185026.07639529.davem@davemloft.net>
	<1163127327.4982.79.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1113
Lines: 27

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Fri, 10 Nov 2006 13:55:27 +1100

> > pci_alloc_consistent() is not allowed from atomic contexts.
> 
> Yes, but some drivers did it anyway, though I can't remember under which
> circumstances (IDE probe possibly ? It's a usual culprit for that sort
> of thing). This is why most implementations use GFP_ATOMIC (including
> sparc64 :-)

Ok, I see.

> Oh well, I have no problem with leaving sparc32 do GFP_KERNEL indeed, I
> can't remember for sure the reason why we have most architectures do
> GFP_ATOMIC, but it probably never hit sparc32.

I wish sparc32 hadn't used alloc_resource() as a poor-man's bitmap
allocator to keep track of IOMMU mappings.  That's where the
GFP_KERNEL requirement comes from.

Just use GFP_KERNEL for now, and someone might find the strength
to remove this problem some day :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/