Re: [PATCHSET] block: fix PIO cache coherency bug, take 2

[Russell King <rmk+lkml@arm.linux.org.uk>]

On Mon, Jun 05, 2006 at 09:27:36AM -0500, James Bottomley wrote:
> 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
> IDE).

When a user program wants to obtain data from a block device, there are
two ways it goes about it:

1. via read().  Read copies the data out of the kernel mapping of the
   page cache, so there's no coherency issues as far as PIO is concerned.

2. via a page which has been mmap()'d.  In this case, we are performing a
   "PIO read from device write" operation to page to fill the page cache
   with data, which must complete _before_ we hand the page to userspace.

In neither case will the page be available to the user before the PIO
operation has been completed - if it was, there would be one very big
security hole since the previous data would be visible.

Hence I find your comment "There are two cases where devices kmap a
user page into kernel space and then proceed to read from or write to
it" to be misleading - at the exact point in time that the device
driver is manipulating the data in that page, it is not a user page.

> > 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 ...

Here we fundamentally disagree - and I'm afraid that it seems that you
didn't actually read what I wrote since there's an obvious disparity
between me saying "if the page has not been mapped into userspace" and
you saying "the page is almost always mapped initially in user space" -
we're _definitely_ talking about different things here.

How can we proceed with this if this kind of misintepretation is rampant?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core