Messages in this thread | | | Date | Fri, 10 Dec 2021 10:20:06 +0100 | From | Michal Hocko <> | Subject | Re: [PATCH v4 1/3] mm: protect free_pgtables with mmap_lock write lock in exit_mmap |
| |
On Thu 09-12-21 11:03:11, Suren Baghdasaryan wrote: > On Thu, Dec 9, 2021 at 12:55 AM Michal Hocko <mhocko@suse.com> wrote: > > > > On Wed 08-12-21 13:22:09, Suren Baghdasaryan wrote: > > > oom-reaper and process_mrelease system call should protect against > > > races with exit_mmap which can destroy page tables while they > > > walk the VMA tree. oom-reaper protects from that race by setting > > > MMF_OOM_VICTIM and by relying on exit_mmap to set MMF_OOM_SKIP > > > before taking and releasing mmap_write_lock. process_mrelease has > > > to elevate mm->mm_users to prevent such race. Both oom-reaper and > > > process_mrelease hold mmap_read_lock when walking the VMA tree. > > > The locking rules and mechanisms could be simpler if exit_mmap takes > > > mmap_write_lock while executing destructive operations such as > > > free_pgtables. > > > Change exit_mmap to hold the mmap_write_lock when calling > > > free_pgtables and remove_vma. Operations like unmap_vmas and > > > unlock_range are not destructive and could run under mmap_read_lock > > > but for simplicity we take one mmap_write_lock during almost the entire > > > operation. > > > > unlock_range is not safe to be called under read lock. See 27ae357fa82b > > ("mm, oom: fix concurrent munlock and oom reaper unmap, v3"). > > Ok, I'll remove the sentence above. > Is my understanding correct that it is unsafe only because oom-reaper > can't deal with VM_LOCKED, otherwise it would be fine?
The commit message (27ae357fa82b) goes into details that I have forgot already. -- Michal Hocko SUSE Labs
| |