Re: [PATCH] Fix vmtruncate race and distributed filesystem race

["Paul E. McKenney" <paulmck@us.ibm.com>]

On Mon, Jun 23, 2003 at 10:10:16AM +0200, Andrea Arcangeli wrote:
> On Mon, Jun 23, 2003 at 12:56:23AM -0700, Andrew Morton wrote:
> > Andrea Arcangeli <andrea@suse.de> wrote:
> > >
> > > that will finally close the race
> > 
> > Could someone please convince me that we really _need_ to close it?
> > 
> > The VM handles the whacky pages OK (on slowpaths), and when this first came
> > up two years ago it was argued that the application was racy/buggy
> > anyway.  So as long as we're secure and stable, we don't care.  Certainly
> > not to the point of adding more atomic ops on the fastpath.
> > 
> > So...   what bug are we actually fixing here?
> 
> we're fixing userspace data corruption with an app trapping SIGBUS.

This handling of wacky pages apparently does not carry over into some
of the rmap optimizations, but I will let dmccr speak to that.

> > (I'd also like to see a clearer description of the distributed fs problem,
> > and how this fixes it).
> 
> I certainly would like discussions about it too.

The race is as follows:

	Node 0				Node 1

	mmap()s file f1
					writes to f1
					sends msg to Node 0 requesting data
	pgflt on mmap
	do_no_page() invokes ->nopage
	->nopage hands page up
	<some interrupt or other delay>

	receives message from Node 1
	invokes invalidate_mmap_range()
	returns data to Node 1

					receives data from Node 0
					does write

	<return from interrupt or whatever>
	do_no_page() installs now-stale mapping
	return from page fault
	application scribbles on page, violating DFS's consistency!!!

Now Node 0 and Node 1 have inconsistent versions of the page being
written to.  Note that this problem occurs regardless of the mechanism
that Node 1 does to accomplish the write -- mmap(), write(), whatever.

This race is a problem only in distributed filesystems that provide
the same consistency guarantees normally found on local filesystems.
Things like NFS or AFS would not be bothered, since they do not offer
such consistency guarantees.  For example, with AFS, the last guy
to close the file wins.

						Thanx, Paul
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>