On Sun, Jan 10, 2021 at 11:30:57AM -0800, Linus Torvalds wrote: > Notice how this is all both conceptually fairly simple (ie I can > explain the rules in plain English without really making any complex > argument) and it is arguably internally fairly self-consistent (ie the > whole notion of "oh, there's another thing that has write access that > page but doesn't go through the page table, so trying to make it > read-only in the page tables is a nonsensical operation"). Yes exactly! > Are the end results wrt something like soft-dirty a bit odd? Not > really. If you do soft-dirty, such a GUP-shared page would simply > always show up as dirty. That's still consistent with the rules. If > somebody else may be writing to it because of GUP, that page really > *isn't* clean, and us marking it read-only would be just lying about > things. > > I'm admittedly not very happy about mprotect() itself, though. It's > actually ok to do the mprotect(PROT_READ) and turn the page read-only: > that will also disable COW itself (because a page fault will now be a > SIGSEGV, not a COW). I would say even mprotect should not set write protect on page under DMA, it seems like the sort of thing that will trip up other parts of the mm that might sensibly assume read-only actually means read only, not 'probably read-only but there might be DMA writes anyhow' So copy the page before write protecting it? Then the explicit mprotect is one of the system calls that can cause de-coherence of the DMA - like munmap. If we had reliable pinned detection I'd say to fail the mprotect.. And I think you are right about clear refs too. Clear refs must be aware of FOLL_LONGTERM and handle it properly - which includes not write protecting such a page. Jason
