[lkml]   [2003]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc)
On 22 Aug 2003 20:09:30 -0500
James Bottomley <> wrote:

> What we were hoping is that we could rely on this little property of
> mmap:
> 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 :(
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: 2005-03-22 13:48    [W:0.086 / U:2.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site