Re: [PATCH v4 1/6] mm: enable page walking API to lock vmas during the walk

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

>
>





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux