On Thu 13-09-18 20:53:24, Tetsuo Handa wrote: > On 2018/09/13 20:35, Michal Hocko wrote: > >> Next question. > >> > >> /* Use -1 here to ensure all VMAs in the mm are unmapped */ > >> unmap_vmas(&tlb, vma, 0, -1); > >> > >> in exit_mmap() will now race with the OOM reaper. And unmap_vmas() will handle > >> VM_HUGETLB or VM_PFNMAP or VM_SHARED or !vma_is_anonymous() vmas, won't it? > >> Then, is it guaranteed to be safe if the OOM reaper raced with unmap_vmas() ? > > > > I do not understand the question. unmap_vmas is basically MADV_DONTNEED > > and that doesn't require the exclusive mmap_sem lock so yes it should be > > safe those two to race (modulo bugs of course but I am not aware of any > > there). > > > > You need to verify that races we observed with VM_LOCKED can't happen > for VM_HUGETLB / VM_PFNMAP / VM_SHARED / !vma_is_anonymous() cases. Well, VM_LOCKED is kind of special because that is not a permanent state which might change. VM_HUGETLB, VM_PFNMAP resp VM_SHARED are not changed throughout the vma lifetime. -- Michal Hocko SUSE Labs
