On Sat, Dec 18, 2021 at 2:52 PM Kirill A. Shutemov kirill@shutemov.name wrote:
So you are saying that if a GUP user wants to see changes made by userspace to the page after the GUP it must ask for FOLL_WRITE, even if it doesn't have intend to write to the page?
Yup. Put the onus very clearly on GUP.
It's a very special operation, and it's one of the operations that cause a lot of problems for the VM code. It's by no means the _only_ one - we've got a lot of other things that cause issues - but I think it's very clear that GUP is very very special, and nobody should say "I want GUP to do whatever".
There are two cases for GUP:
- look up the page as it is *NOW*
- look up the page in order to see any future state on it (and possibly modify it)
that "any future state" is a fundamentally much heavier operation. It's the one that really *has* to get rid of any sharing, and it has to make sure no sharing happens in the future either.
So ii it is an anonymous page, it basically needs to act like a write. Even if that page is then used only for reading.
Note that here that "if it's anonymous" is kind of a big deal. If it's a shared file-mapped page, at that point it's "just another reference". It's potentially problematic even in that case (think of "truncate()" that tries to force-unmap all pages from VM's), but for the shared case the answer is "if you truncate it and disassociate the page from the mapping, it's _your_ problem.
And once it acts as a write, and once it does that COW and we have exclusive access to it, it might as well be just writable and dirty. You've done the expensive part already. You've forced it to be private to that VM.
And this was all triggered by the user doing something very special, so no amount of "but POSIX" or whatever matters.
GUP is not great. If you use GUP, you get to deal with the downsides.
Linus