From: Sebastian Andrzej Siewior <sebastian@xxxxxxxxxxxxx> Date: Mon, 1 Mar 2010 20:58:58 +0100 > The part I don't get is why you have to flush dcache after the copy > process. I would understand a flush before reading. The dcache alias in > kernel shouldn't hurt since it is not used anymore. Unless we read twice > from the same page. Is this the trick? Anything that puts the data into the cache on the kernel side is a problem. The page is still potentially in user space, as a result there will be thus two active mappings in the cache, one in the kernel side and one in the user side. The user can then do various operations which can access either mapping. Writing to it via write() system call, writing to it via mmap(), making the kernel write to it by doing a read() with the buffer pointing into the mmap() area. All we need is a modification on either side for the other one to potentially become stale. >>Secondly, IDE is in deep maintainence mode, if you want to optimize >>cache flushing do it in the ATA layer. > This patch patch was mostly driven by the fact that the buffer can be a > normal kernel mapping or a virtual address. The latter doesn't work with > virt_to_page(). > Anyway I should probably spent more time getting ATA layer wokring than > on the IDE layer since it is somehow working since patch#1. All buffers passed to the architecture IDE ops should be PAGE_OFFSET relative kernel virtual addresses for which __pa() works. Are kmap()'d things ending up here? It all works out on sparc64 because we don't have highmem and kernel stacks are just in normal kernel pages.
