Re: [PATCH v2 1/2] mm/rmap: fix and simplify reusing mergeable anon_vma as parent when fork

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

 



On 2020-01-13 at 19:07 Konstantin Khlebnikov wrote:

>
>Because I want to keep both heuristics.
>This seems most sane way of interaction between them.
>
>Unfortunately even this patch is slightly broken.
>Condition prev->anon_vma->parent == pvma->anon_vma doesn't guarantee that
>prev vma has the same set of anon-vmas like current vma.
>I.e. anon_vma_clone(vma, prev) might be not enough for keeping connectivity. 

New patch is required?
It is necessary to call anon_vma_clone(vma, pvma) to link all anon_vma which
currently linked by pvma, then link the prev->anon_vma to vma. By this way,
connectivity of vma should be maintained, right?

>Building such case isn't trivial job but I see nothing that could prevent it.
>





[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