On 03.03.22 02:47, John Hubbard wrote: > 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, that's extremely helpful. I forgot about these MAP_PRIVATE mmap() details -- they help a lot to clarify which semantics to provide. So what we could do is: a) Extend FAULT_FLAG_UNSHARE to also unshare an !anon page in a MAP_RPIVATE mapping, replacing it with an (exclusive) anon page. R/O PTE permissions are maintained, just like unsharing in the context of this series. b) Similarly trigger FAULT_FLAG_UNSHARE from GUP when trying to take a R/O pin (FOLL_PIN) on a R/O-mapped !anon page in a MAP_PRIVATE mapping. c) Make R/O pins consistently use "FOLL_PIN" instead, getting rid of FOLL_FORCE|FOLL_WRITE. Of course, we can't detect MAP_PRIVATE vs. MAP_SHARED in GUP-fast (no VMA), so we'd always have to fallback in GUP-fast in case we intend to FOLL_PIN a R/O-mapped !anon page. That would imply that essentially any R/O pins (FOLL_PIN) would have to fallback to ordinary GUP. BUT, I mean we require FOLL_FORCE|FOLL_WRITE right now, which is not any different, so ... One optimization would be to trigger b) only for FOLL_LONGTERM. For !FOLL_LONGTERM there are "in theory" absolutely no guarantees which data will be observed if we modify concurrently to e.g., O_DIRECT IMHO. But that would require some more thought. Of course, that's all material for another journey, although it should be mostly straight forward. -- Thanks, David / dhildenb
