On Wed, 2012-08-01 at 13:10 -0500, Christoph Lameter wrote:

On Wed, 1 Aug 2012, Glauber Costa wrote:

quoted

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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>