On Sun, Sep 26, 2021 at 09:12:52AM -0700, Nadav Amit wrote: > From: Nadav Amit <namit@xxxxxxxxxx> > > The comment in madvise_dontneed_free() says that vma splits that occur > while the mmap-lock is dropped, during userfaultfd_remove(), should be > handled correctly, but nothing in the code indicates that it is so: prev > is invalidated, and do_madvise() will therefore continue to update VMAs > from the "obsolete" end (i.e., the one before the split). > > Propagate the changes to end from madvise_dontneed_free() back to > do_madvise() and continue the updates from the new end accordingly. Could you describe in details a race that would lead to wrong behaviour? If mmap lock was dropped any change to VMA layout can appear. We can have totally unrelated VMA there. Either way, if userspace change VMA layout for a region that is under madvise(MADV_DONTNEED) it is totally broken. I don't see a valid reason to do this. The current behaviour looks reasonable to me. Yes, we can miss VMAs, but these VMAs can also be created just after madvise() is finished. -- Kirill A. Shutemov
