Re: invalidate_inode_pages2

[Andrea Arcangeli <andrea@suse.de>]

On Wed, May 19, 2004 at 01:08:01AM -0400, Jan Harkes wrote:
> On Wed, May 19, 2004 at 02:51:06AM +0200, Andrea Arcangeli wrote:
> > On Tue, May 18, 2004 at 05:27:18PM -0700, Andrew Morton wrote:
> > > Andrea Arcangeli <andrea@suse.de> wrote:
> > > >
> > > > Something broke in invalidate_inode_pages2 between 2.4 and 2.6, this
> > > > causes malfunctions with mapped pages in 2.6.
> > > 
> > > What is the malfunction?
> > 
> > From Olaf Kirch
> > 
> >  -      single application on NFS client opens file and maps it.
> >         No-one else has this file open. File contains "zappa\n",
> >         and the test app stats it once a second and reports size and
> >         contents.
> >         len=6, data=7a 61 70 70 61 0a
> >  -      on the NFS server, I do "echo frobnorz > file"
> >  -      after a while, the test app on the client reports
> >         len=10, data=7a 61 70 70 61 0a
> 
> I'm mostly just curious, what exactly happens when a second process
> opens and mmaps the file at this point? Will it also see the new length
> with the old data, or will that invalidate the mapping and pull the new
> data off of the server?

depends if the new process will generate page faults or not. if it
generates page faults it will re-read the pages from the server while
the other task runs.

> Also what happens if the process had a shared mapping and dirtied the
> page (f.i. it wrote a byte to to offset 0) but the update hasn't yet
> been written back, will it end up committing the (stale) data from the
> local copy of the page but with the updated length=10 back to the server?

it will not commit the stale data because the invalidate clears the
dirty bit, again the new data will arrive from the server. Note that if
there's some VM paging in the client NFS side, the very same task can
pull the data again from the nfs server during pagein (the writeback
during pageout will not happen because the cache has been invalidated
and the dirty bit has been lost).