lkml.org 
[lkml]   [2004]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Non-GPL export of invalidate_mmap_range
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:01    [from the cache]
©2003-2011 Jasper Spaans