Re: [PATCH 2/3] Revert "mm/rmap.c: reuse mergeable anon_vma as parent when fork"

["Kirill A. Shutemov" <kirill@shutemov.name>]

On Sat, Feb 08, 2020 at 08:35:27AM +0000, Li Xinhai wrote:
> This reverts commit 4e4a9eb921332b9d1edd99f76998f99f36b195f7
> In dup_mmap(), anon_vma_fork() is called for attaching anon_vma and
> parameter 'tmp'  (i.e., the new vma of child) has same ->vm_next and
> ->vm_prev as its parent vma. That causes the anon_vma used by parent been
> mistakenly shared by child (In anon_vma_clone(), the code added by that
> commit will do this reuse work).
> 
> Besides this issue, the design of reusing anon_vma from vma which has
> gone through fork should be avoided ([1]). So, this patch reverts that
> commit and maintains the consistent logic of reusing anon_vma for
> fork/split/merge vma.
> 
> [1] commit d0e9fe1758f2 ("Simplify and comment on anon_vma re-use for
>     anon_vma_prepare()") explains the test of "list_is_singular()".

I read the description few time, but I cannot say I understood the
problem completely. Do you have a test-case to demonstrate the issue?

IIUC, re-using anon_vma across fork is wrong, but within the process is
fine, right?

Maybe we should just check that dst->vm_mm matches src->vm_mm before
re-using anon_vma?

-- 
 Kirill A. Shutemov