[lkml]   [2006]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCHSET] block: fix PIO cache coherency bug, take 2
On Sun, 2006-06-04 at 23:23 +0100, Russell King wrote:
> I'll add to this statement that the cache flushing on ARM is only
> ever required when the page ends up in userspace - if we're reading
> a page into the page cache to throw it out via NFS or sendfile then
> the cache flush is a complete waste of time.

Right .. and this is the scenario. There are two cases where devices
kmap a user page into kernel space and then proceed to read from or
write to it (flush_dcache_page() is specifically for the latter because
the user won't see the data the kernel just wrote unless this happens
because kernel and user addresses aren't congruent on parisc).

The first case is manufactured data (such as command emulation) and the
second is pio data rather than DMA (such as command re-completion or

> In this respect, I continue to believe that the way ARM (in principle)
> does flush_dcache_page() is what is required here - if the page has
> not been mapped into userspace, it merely marks the page as containing
> dirty cache lines, and the resulting cache maintainence will only
> happen when (and if) the page really does get mapped into userspace.

For this particular scenario, the page is almost always mapped initially
in user space because the user is requesting the I/O to a given
userspace address ... get_user_pages() ensures that it is allocated and
flushed before being passed to IDE or SCSI.

The problem on parisc, however, is not that userspace doesn't see the
page as dirty, it's that we've dirtied the page through the kernel
mappings, so userspace itself cannot possibly see the change until the
cache over the kernel address is flushed (the userspace and kernel space
addresses are not congruent in our cache scheme, so get separate cache


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-06-05 16:31    [W:0.081 / U:3.828 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site