On Fri, Dec 17, 2021 at 12:47 PM Jason Gunthorpe <jgg@xxxxxxxxxx> wrote:
>
> To remind all, the GUP users, like RDMA, VFIO use
> FOLL_FORCE|FOLL_WRITE to get a 'r/o pin' specifically because of the
> COW breaking the coherence. In these case 'r/o pin' does not mean
> "snapshot the data", but its only a promise not to write to the pages
> and still desires coherence with the memory map.
>
> Eg in RDMA we know of apps asking for a R/O pin of something in .bss
> then filling that something with data finally doing the actual
> DMA. Breaking COW after pin breaks those apps.
I agree.
And my argument is that those kinds of things that ask for a R/O pin
are broken, and should just make sure to use the shared pins.
If the page was already writable, you can just re-use the page
directly (marking it pinned, so that any subsequent fork() does the
right pre-cow thing)
And if the page was *NOT* already writable, you do a COW - which might
be sharing the page directly too, if it has no other references.
What's the downside of just doing this properly?
Again: if a DMA user wants coherent memory, then it should use the
coherent pinning. Not some kind of "read-only sharing that looks at
crazy mapcounts that have absolutely zero relevance to whether the
page is coherent or not".
Linus
