Messages in this thread | | | Date | Thu, 09 Nov 2006 18:50:26 -0800 (PST) | Subject | Re: DMA APIs gumble grumble | From | David Miller <> |
| |
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: Fri, 10 Nov 2006 12:02:04 +1100
> > Please just mirror what I did on sparc64 for sparc32, see changeset > > 42f142371e48fbc44956d57b4e506bb6ce673cd7, with followup bug fixes > > in 36321426e320c2c6bc2f8a1587d6f4d695fca84c and > > 7233589d77fdb593b482a8b7ee867e901f54b593. > > Question about sparc. It's implementation of pci_alloc_consistent(), > unlike the other ones from before we had a GFP mask massed, does > GFP_KERNEL allocations and not GFP_ATOMIC. Thus it's never expected to > be called in atomic context. In fact, it does various other things like > calling allocate_resource which is not something you ever want to be > called from interrupt context.
pci_alloc_consistent() is not allowed from atomic contexts.
> I'm splitting it into a pci_do_alloc_consistent that takes a gfp arg, > and a pair of pci_alloc_consistent & dma_alloc_consistent wrappers. > > Do you think I should have the former pass GFP_KERNEL like the current > implementation does or switch it to GFP_ATOMIC like everybody does ? In > this case, should I also change the kmalloc done in there to allocate a > struct resource to use the gfp argument ? (It's currently doing > GFP_KERNEL).
pci_alloc_consistent() really cannot be allowed to use GFP_ATOMIC. - 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/
| |