On Fri, Aug 4, 2023 at 7:14 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, 4 Aug 2023 08:27:19 -0700 Suren Baghdasaryan <surenb@xxxxxxxxxx> wrote: > > > walk_page_range() and friends often operate under write-locked mmap_lock. > > With introduction of vma locks, the vmas have to be locked as well > > during such walks to prevent concurrent page faults in these areas. > > Add an additional member to mm_walk_ops to indicate locking requirements > > for the walk. > > > > ... > > > > 18 files changed, 100 insertions(+), 20 deletions(-) > > > > That's a big patch for a -stable backport. > > Presumably the various -stable maintainers will be wondering why we're > doing this. But, as is so often the case, the changelog fails to > describe any user-visible effects of the change. Please send this info > and I'll add it to the changelog. The change ensures that page walks which prevent concurrent page faults by write-locking mmap_lock, operate correctly after introduction of per-vma locks. With per-vma locks page faults can be handled under vma lock without taking mmap_lock at all, so write locking mmap_lock would not stop them. The change ensures vmas are properly locked during such walks. A sample issue this solves is do_mbind() performing queue_pages_range() to queue pages for migration. Without this change a concurrent page can be faulted into the area and be left out of migration. > >
