Re: [PATCH RFC 12/13] mm/gup: trigger FAULT_FLAG_UNSHARE when R/O-pinning a possibly shared anonymous page

[John Hubbard <jhubbard@nvidia.com>]

On 3/2/22 12:38, David Hildenbrand wrote:
...
> BUT, once we actually write to the private mapping via the page table,
> the GUP pin would go out of sync with the now-anonymous page mapped into
> the page table. However, I'm having a hard time answering what's
> actually expected?
> 
> It's really hard to tell what the user wants with MAP_PRIVATE file
> mappings and stumbles over a !anon page (no modifications so far):
> 
> (a) I want a R/O pin to observe file modifications.
> (b) I want the R/O pin to *not* observe file modifications but observe
>      my (eventual? if any) private modifications,
> 

On this aspect, I think it is easier than trying to discern user
intentions. Because it is less a question of what the user wants, and
more a question of how mmap(2) is specified. And the man page clearly
indicates that the user has no right to expect to see file
modifications. Here's the excerpt:

"MAP_PRIVATE
	
Create  a private copy-on-write mapping.  Updates to the mapping are not
visible to other processes mapping the same file, and are not carried
through to the underlying file.  It is unspecified whether changes  made
to the file after the mmap() call are visible in the mapped region.
"

> Of course, if we already wrote to that page and now have an anon page,
> it's easy: we are already no longer following file changes.

Yes, and in fact, I've always thought that the way this was written
means that it should be treated as a snapshot of the file contents,
and no longer reliably connected in either direction to the page(s).


thanks,
-- 
John Hubbard
NVIDIA