While I have a patch queued to address related issues in intel-agp, a quick scan
of the Linux tree seems to reveal several more cases where assumptions are
being made on GFP_DMA{,32} allocations - either the result (even properly
passed through virt_to_bus()) is put into hardware registers (with no
guarantee that it fits the width required by those registers or fields thereof),
or page-crossing arithmetic is being done (explicitly or implicitly). All this
is set
to cause data corruption.
Are there any ideas, other than either suppressing such components or fixing
them one by one, how to address this problem?
Thanks, Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
How many callers rely on GFP_DMA32? We gave up on GFP_DMA because no halfway modern hardware relies on it and we can''t currently satisfy requests for memory below 16MB anyway. As for solutions, either we have to hook the memory allocator somehow to get a call out to allocate memory of the correct type, or callers do indeed need fixing one by one. -- Keir On 3/4/07 15:34, "Jan Beulich" <jbeulich@novell.com> wrote:> While I have a patch queued to address related issues in intel-agp, a quick > scan > of the Linux tree seems to reveal several more cases where assumptions are > being made on GFP_DMA{,32} allocations - either the result (even properly > passed through virt_to_bus()) is put into hardware registers (with no > guarantee that it fits the width required by those registers or fields > thereof), > or page-crossing arithmetic is being done (explicitly or implicitly). All this > is set > to cause data corruption. > > Are there any ideas, other than either suppressing such components or fixing > them one by one, how to address this problem?_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 04.04.07 09:11 >>> >How many callers rely on GFP_DMA32? We gave up on GFP_DMA because no halfway >modern hardware relies on it and we can''t currently satisfy requests for >memory below 16MB anyway.For GFP_DMA, I stopped counting when I found the third or fourth one - the grep indicated another dozen or so candidates. For GFP_DMA32, it''s just two (all agp drivers, which I said I have a fix for, and drivers/media/video/video-buf.c - there are many suspicious virt_to_phys() uses underneath drivers/media/, so this subtree looks broken in general). In may cases GFP_DMA is just being used to restrict memory to somewhere below 32-bits, not necessarily to 24.>As for solutions, either we have to hook the memory allocator somehow to get >a call out to allocate memory of the correct type, or callers do indeed need >fixing one by one.I thought about possible hooks, too, but after a page was allocated you don''t know what GFP_* it was allocated with. The only not too intrusive way I could immediately think of would be to further leverage PG_foreign here, but I''m afraid its use of page->index may then get into conflict with other uses... Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel