From: Sebastian Andrzej Siewior <firstname.lastname@example.org>
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
> 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.