Re: Non-GPL export of invalidate_mmap_range

[Paul E. McKenney]

On Thu, Feb 19, 2004 at 05:31:33PM -0500, Daniel Phillips wrote:
> Hi Stephen,
> 
> On Thursday 19 February 2004 17:06, Stephen C. Tweedie wrote:
> > Hi,
> >
> > On Thu, 2004-02-19 at 20:56, Daniel Phillips wrote:
> > > OpenGFS and Sistina GFS use zap_page_range directly, essentially doing
> > > the same as invalidate_mmap_range but skipping any vmas belonging to
> > > MAP_PRIVATE mmaps.
> >
> > Well, MAP_PRIVATE maps can contain shared pages too --- any page in a
> > MAP_PRIVATE map that has been mapped but not yet written to is still
> > shared, and still needs shot down on truncate().
> 
> Exactly, and we ought to take this opportunity to do that properly, which is 
> easy.  I'm just curious how GPFS deals with this issue, or if it simply 
> doesn't support MAP_PRIVATE.

GPFS supports MAP_PRIVATE, but does not specify the behavior if you
change the underlying file.  There are a number of things one can do,
but one must keep in mind that different processes can MAP_PRIVATE the
same file at different times, and that some processes might MAP_SHARED it
at the same time that others MAP_PRIVATE it.  Here are the alternatives
I can imagine:

1.	Any time a file changes, create a copy of the old version
	for any MAP_PRIVATE vmas.  This would essentially create
	a point-in-time copy of any file that a process mapped
	MAP_PRIVATE.  This is arguably the most intuitive from the
	user's standpoint, but (a) it would not be a small change and
	(b) I haven't heard of anyone coming up with a good use for it.
	Please enlighten me if I am missing a simple implementation or
	compelling uses.

2.	Modify invalidate_mmap_range() to leave MAP_PRIVATE vmas.
	as suggested by Daniel.  This would mean that a
	process that had mapped a file MAP_PRIVATE and faulted
	in parts of it would see different versions of the file
	in different pages.  This should be straightforward to
	implement, but in what situation is this skewed view of
	the file useful?

3.	Modify invalidate_mmap_range() to leave MAP_PRIVATE vmas,
	but invalidate those pages in the vma that have not yet been
	modified (that are not anonymous) as suggested by Stephen.
	This would mean that a process that had mapped a file MAP_PRIVATE
	and written on parts of it would see different versions of the
	file in different pages.  Again, in what situation is this skewed
	view of the file useful?

5.	The current behavior, where the process's writes do not
	flow through to the file, but all changes to the file are
	visible to the writing process.

6.	Requiring that MAP_PRIVATE be applied only to unchanging
	files, so that (for example) any change to the underlying
	file removes that file from any MAP_PRIVATE address spaces.
	Subsequent accesses would get a SEGV, rather than a
	surprise from silently changing data.

So, please help me out here...  What do applications that MAP_PRIVATE
changing files really expect to happen?

						Thanx, Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/