Messages in this thread | | | Date | Mon, 2 Oct 2023 19:36:01 +0200 | Subject | Re: [PATCH v2 2/3] userfaultfd: UFFDIO_REMAP uABI | From | David Hildenbrand <> |
| |
On 02.10.23 19:33, David Hildenbrand wrote: > On 02.10.23 17:21, Peter Xu wrote: >> On Mon, Oct 02, 2023 at 10:00:03AM +0200, David Hildenbrand wrote: >>> In case we cannot simply remap the page, the fallback sequence (from the >>> cover letter) would be triggered. >>> >>> 1) UFFDIO_COPY >>> 2) MADV_DONTNEED >>> >>> So we would just handle the operation internally without a fallback. >> >> Note that I think there will be a slight difference on whole remap >> atomicity, on what happens if the page is modified after UFFDIO_COPY but >> before DONTNEED. > > If the page is writable (implies PAE), we can always move it. If it is > R/O, it cannot change before we get a page fault and grab the PT lock > (well, and page lock). > > So I think something atomic can be implemented without too much issues. > >> >> UFFDIO_REMAP guarantees full atomicity when moving the page, IOW, threads >> can be updating the pages when ioctl(UFFDIO_REMAP), data won't get lost >> during movement, and it will generate a missing event after moved, with >> latest data showing up on dest. > > If the page has to be copied, grab a reference and unmap it, then copy > it and map it into the new process. Should be doable and handle all > kinds of situations just fine. > > Just throwing out ideas to get a less low-level interface. > > [if one really wants to get notified when one cannot move without a > copy, one could have a flag for such power users to control the behavior] >
[of course, if someone would have a GUP-pin on such a page, the page exchange would be observable. Just have to documented the UFFDIO_MOVE semantics properly]
-- Cheers,
David / dhildenb
| |