On Wed, Feb 26, 2020 at 05:08:08PM +0100, David Hildenbrand wrote: > On 26.02.20 17:06, Peter Xu wrote: > > On Wed, Feb 26, 2020 at 04:53:04PM +0100, David Hildenbrand wrote: > >> When we partially change mappings (esp., mmap over parts of an existing > >> mmap like qemu_ram_remap() does) where we have a userfaultfd handler > >> registered, the handler will implicitly be unregistered from the parts that > >> changed. > >> > >> Trying to place pages onto mappings where there is no longer a handler > >> registered will fail. Let's make sure that any waiter is woken up - we > >> have to do that manually. > >> > >> Let's also document how UFFDIO_UNREGISTER will handle this scenario. > >> > >> This is mainly a preparation for RAM blocks with resizable allcoations, > >> where the mapping of the invalid RAM range will change. The source will > >> keep sending pages that are outside of the new (shrunk) RAM size. We have > >> to treat these pages like they would have been migrated, but can > >> essentially simply drop the content (ignore the placement error). > >> > >> Keep printing a warning when we hit EINVAL, to avoid hiding other > >> (programming) issues. ENOENT is unique. > >> > >> Cc: "Dr. David Alan Gilbert" <dgilb...@redhat.com> > >> Cc: Juan Quintela <quint...@redhat.com> > >> Cc: Peter Xu <pet...@redhat.com> > >> Cc: Andrea Arcangeli <aarca...@redhat.com> > >> Signed-off-by: David Hildenbrand <da...@redhat.com> > > > > Reviewed-by: Peter Xu <pet...@redhat.com> > > > > Thanks a lot! > > BTW, while I am playing with userfaultfd, I already have patches to > factor out all uffd handling from postcopy code into utils/uffd.c > > My list of patches does not seem to get any smaller :(
Simply because you're working on more things? :) Thanks for working on this (and this is far better than the exit() version, IMHO)! -- Peter Xu
