On Wed, 2012-08-01 at 13:10 -0500, Christoph Lameter wrote: > On Wed, 1 Aug 2012, Glauber Costa wrote: > > > I've audited all users of get_page() in the drivers/ directory for > > patterns like this. In general, they kmalloc something like a table of > > entries, and then get_page() the entries. The entries are either user > > pages, pages allocated by the page allocator, or physical addresses > > through their pfn (in 2 cases from the vga ones...) > > > > I took a look about some other instances where virt_to_page occurs > > together with kmalloc as well, and they all seem to fall in the same > > category. > > The case that was notorious in the past was a scsi control structure > allocated from slab that was then written to the device via DMA. And it > was not on x86 but some esoteric platform (powerpc?), > > A reference to the discussion of this issue in 2007: > > http://lkml.indiana.edu/hypermail/linux/kernel/0706.3/0424.html What you wrote above bears no relation to the thread. The thread is a long argument about what flush_dcache_page() should be doing if called on slab memory. Hugh told you about five times: "nothing". Which is the correct answer since flush_dcache_page() is our user to kernel memory coherence API ... it's actually nothing to do with DMA although it can be used to cause coherence for the purposes for DMA, but often it's simply used to allow the kernel to write to or read from user memory. What you seem to be worried about is DMA cache line interference caused by object misalignment? But even in what you wrote above it's clear you don't understand what that actually is. As long as you flush correctly, you can never actually get DMA cache line interference on memory being sent to a device via DMA ... however misaligned it is. The killer case is unresolvable incoherencies when you DMA *from* a device. For this case, if you have a cache line overlapping an object like this -------------------------------- OBJ | Other OBJ -------------------------------- | CPU Cache line | -------------------------------- If OBJ gets its underlying page altered by DMA at the same time someone writes to other OBJ (causing the CPU to pull in the cache line with the old pre-DMA value for OBJ and then dirty the component for Other OBJ), you have both a dirty cache line and altered (i.e. dirty) underlying memory. Here an invalidate will destroy the update to other OBJ and a flush will destroy the DMA update to OBJ, so the alias is unresolvable. Is that what the worry is? James -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>