Re: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc)

["David S. Miller" <davem@redhat.com>]

On 22 Aug 2003 20:09:30 -0500
James Bottomley <James.Bottomley@SteelEye.com> wrote:

> What we were hoping is that we could rely on this little property of
> mmap:
> 
>        MAP_PRIVATE
>                   Create a private copy-on-write mapping.  Stores
>                   to the region do not affect the original  file.
>                   It  is  unspecified whether changes made to the
>                   file after the mmap call  are  visible  in  the
>                   mapped region.
> 
> To avoid having to flush the non-shared mappings (basically on parisc if
> you write to a file backing a MAP_PRIVATE mapping then we don't
> guarantee you see the update).
> 
> I suppose if we had a way of telling if any of the i_mmap list members
> were really MAP_SHARED semantics mappings, then we could alter our
> flush_dcache_page() implementation to work.

I thought about this very deeply last night and this morning.
And what you're trying to optimize won't work.  Here is why.

If the first access to a MAP_PRIVATE mapping of a page is a read,
we'll use the page-cache page.  This means that, with your
optimization, during this time if another cpu write()`s into the
page we'll lose the data update.

Sorry :(