Messages in this thread | | | From | Linus Torvalds <> | Date | Fri, 17 Dec 2021 12:56:21 -0800 | Subject | Re: [PATCH v1 06/11] mm: support GUP-triggered unsharing via FAULT_FLAG_UNSHARE (!hugetlb) |
| |
On Fri, Dec 17, 2021 at 12:47 PM Jason Gunthorpe <jgg@nvidia.com> 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
| |