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

Paul E. McKenney (paulmck@us.ibm.com)
Mon, 23 Jun 2003 18:37:01 -0700


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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/