On Sun, 13 Oct 2019 20:10:06 -0700 syzbot <syzbot+3370fc9fb190f98c5...@syzkaller.appspotmail.com> wrote:
> syzbot found the following crash on: > > HEAD commit: 442630f6 Add linux-next specific files for 20191008 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=11450d93600000 > kernel config: https://syzkaller.appspot.com/x/.config?x=af1bfeef713eefdd > dashboard link: https://syzkaller.appspot.com/bug?extid=3370fc9fb190f98c5c72 > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13132d57600000 > > The bug was bisected to: > > commit 480706f51e2c3a450d2f7fc10f5af215c9d249df > Author: Wei Yang <richardw.y...@linux.intel.com> > Date: Mon Oct 7 20:25:37 2019 +0000 > > mm/rmap.c: reuse mergeable anon_vma as parent when forking Hopefully the updated version addresses this? From: Wei Yang <richardw.y...@linux.intel.com> Subject: mm/rmap.c: reuse mergeable anon_vma as parent when fork In __anon_vma_prepare(), we will try to find anon_vma if it is possible to reuse it. While on fork, the logic is different. Since commit 5beb49305251 ("mm: change anon_vma linking to fix multi-process server scalability issue"), function anon_vma_clone() tries to allocate new anon_vma for child process. But the logic here will allocate a new anon_vma for each vma, even in parent this vma is mergeable and share the same anon_vma with its sibling. This may do better for scalability issue, while it is not necessary to do so especially after interval tree is used. Commit 7a3ef208e662 ("mm: prevent endless growth of anon_vma hierarchy") tries to reuse some anon_vma by counting child anon_vma and attached vmas. While for those mergeable anon_vmas, we can just reuse it and not necessary to go through the logic. After this change, kernel build test reduces 20% anon_vma allocation. Do the same kernel build test, it shows run time in sys reduced 11.6%. Origin: real 2m50.467s user 17m52.002s sys 1m51.953s real 2m48.662s user 17m55.464s sys 1m50.553s real 2m51.143s user 17m59.687s sys 1m53.600s Patched: real 2m39.933s user 17m1.835s sys 1m38.802s real 2m39.321s user 17m1.634s sys 1m39.206s real 2m39.575s user 17m1.420s sys 1m38.845s Link: http://lkml.kernel.org/r/20191011072256.16275-2-richardw.y...@linux.intel.com Signed-off-by: Wei Yang <richardw.y...@linux.intel.com> Acked-by: Konstantin Khlebnikov <khlebni...@yandex-team.ru> Cc: Kirill A. Shutemov <kirill.shute...@linux.intel.com> Cc: "Jérôme Glisse" <jgli...@redhat.com> Cc: Mike Kravetz <mike.krav...@oracle.com> Cc: Rik van Riel <r...@surriel.com> Cc: Qian Cai <c...@lca.pw> Cc: Shakeel Butt <shake...@google.com> Signed-off-by: Andrew Morton <a...@linux-foundation.org> --- mm/rmap.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) --- a/mm/rmap.c~mm-rmapc-reuse-mergeable-anon_vma-as-parent-when-fork +++ a/mm/rmap.c @@ -268,6 +268,19 @@ int anon_vma_clone(struct vm_area_struct { struct anon_vma_chain *avc, *pavc; struct anon_vma *root = NULL; + struct vm_area_struct *prev = dst->vm_prev, *pprev = src->vm_prev; + + /* + * If parent share anon_vma with its vm_prev, keep this sharing in in + * child. + * + * 1. Parent has vm_prev, which implies we have vm_prev. + * 2. Parent and its vm_prev have the same anon_vma. + */ + if (!dst->anon_vma && src->anon_vma && + pprev && pprev->anon_vma == src->anon_vma) + dst->anon_vma = prev->anon_vma; + list_for_each_entry_reverse(pavc, &src->anon_vma_chain, same_vma) { struct anon_vma *anon_vma; _
