kernel BUG at include/linux/rmap.h:LINE!

8 views
Skip to first unread message

syzbot

unread,
Oct 13, 2019, 11:10:07 PM10/13/19
to ak...@linux-foundation.org, chenji...@huawei.com, ja...@google.com, khleb...@yandex-team.ru, kirill....@linux.intel.com, linux-...@vger.kernel.org, linu...@kvack.org, mho...@suse.com, mike.k...@oracle.com, richar...@linux.intel.com, ri...@surriel.com, s...@canb.auug.org.au, steve....@arm.com, syzkall...@googlegroups.com, tiny....@gmail.com, vba...@suse.cz, wal...@google.com, wi...@infradead.org, yang...@linux.alibaba.com
Hello,

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 <richar...@linux.intel.com>
Date: Mon Oct 7 20:25:37 2019 +0000

mm/rmap.c: reuse mergeable anon_vma as parent when forking

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=107ea520e00000
final crash: https://syzkaller.appspot.com/x/report.txt?x=127ea520e00000
console output: https://syzkaller.appspot.com/x/log.txt?x=147ea520e00000

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+3370fc...@syzkaller.appspotmail.com
Fixes: 480706f51e2c ("mm/rmap.c: reuse mergeable anon_vma as parent when
forking")

prot 25 anon_vma ffff88809a9c4b40 vm_ops 0000000000000000
pgoff 20000 file 0000000000000000 private_data 0000000000000000
flags: 0x8100077(read|write|exec|mayread|maywrite|mayexec|account|softdirty)
------------[ cut here ]------------
kernel BUG at include/linux/rmap.h:159!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 8601 Comm: syz-executor.0 Not tainted 5.4.0-rc2-next-20191008 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:anon_vma_merge include/linux/rmap.h:159 [inline]
RIP: 0010:__vma_adjust+0x151c/0x1cc0 mm/mmap.c:921
Code: 4c 89 ee 4c 89 f7 e8 b3 01 d2 ff 4d 39 ee 0f 82 1b fe ff ff 45 31 ed
e9 1b fe ff ff e8 7d 00 d2 ff 48 8b 7d c8 e8 76 62 fc ff <0f> 0b e8 6d 00
d2 ff 48 8b 85 68 ff ff ff 80 38 00 0f 85 20 07 00
RSP: 0018:ffff8880a0e9f9c0 EFLAGS: 00010286
RAX: 0000000000000147 RBX: dffffc0000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff815cb676 RDI: ffffed10141d3f12
RBP: ffff8880a0e9fa88 R08: 0000000000000147 R09: ffffed1015d06161
R10: ffffed1015d06160 R11: ffff8880ae830b07 R12: ffff888095f28e10
R13: ffff88808c0f7f18 R14: 0000000000000000 R15: 0000000000000001
FS: 0000000000c57940(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020d06000 CR3: 0000000090f89000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
vma_merge+0xb8a/0xe60 mm/mmap.c:1169
mmap_region+0x3e0/0x1760 mm/mmap.c:1741
do_mmap+0x853/0x1190 mm/mmap.c:1552
do_mmap_pgoff include/linux/mm.h:2361 [inline]
vm_mmap_pgoff+0x1c5/0x230 mm/util.c:510
ksys_mmap_pgoff+0xf7/0x630 mm/mmap.c:1604
__do_sys_mmap arch/x86/kernel/sys_x86_64.c:100 [inline]
__se_sys_mmap arch/x86/kernel/sys_x86_64.c:91 [inline]
__x64_sys_mmap+0xe9/0x1b0 arch/x86/kernel/sys_x86_64.c:91
do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x459a59
Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffcc91b5068 EFLAGS: 00000246 ORIG_RAX: 0000000000000009
RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 0000000000459a59
RDX: ffffffffefffffff RSI: 0000000000004000 RDI: 0000000020196000
RBP: 000000000075bf20 R08: ffffffffffffffff R09: 0000000000000000
R10: 0000000000008032 R11: 0000000000000246 R12: 0000000000c57914
R13: 00000000004c6176 R14: 00000000004db118 R15: 00000000ffffffff
Modules linked in:
---[ end trace aa2e499bc1c6fb5e ]---
RIP: 0010:anon_vma_merge include/linux/rmap.h:159 [inline]
RIP: 0010:__vma_adjust+0x151c/0x1cc0 mm/mmap.c:921
Code: 4c 89 ee 4c 89 f7 e8 b3 01 d2 ff 4d 39 ee 0f 82 1b fe ff ff 45 31 ed
e9 1b fe ff ff e8 7d 00 d2 ff 48 8b 7d c8 e8 76 62 fc ff <0f> 0b e8 6d 00
d2 ff 48 8b 85 68 ff ff ff 80 38 00 0f 85 20 07 00
RSP: 0018:ffff8880a0e9f9c0 EFLAGS: 00010286
RAX: 0000000000000147 RBX: dffffc0000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff815cb676 RDI: ffffed10141d3f12
RBP: ffff8880a0e9fa88 R08: 0000000000000147 R09: ffffed1015d06161
R10: ffffed1015d06160 R11: ffff8880ae830b07 R12: ffff888095f28e10
R13: ffff88808c0f7f18 R14: 0000000000000000 R15: 0000000000000001
FS: 0000000000c57940(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020d06000 CR3: 0000000090f89000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

Andrew Morton

unread,
Oct 14, 2019, 6:40:31 PM10/14/19
to syzbot, chenji...@huawei.com, ja...@google.com, khleb...@yandex-team.ru, kirill....@linux.intel.com, linux-...@vger.kernel.org, linu...@kvack.org, mho...@suse.com, mike.k...@oracle.com, richar...@linux.intel.com, ri...@surriel.com, s...@canb.auug.org.au, steve....@arm.com, syzkall...@googlegroups.com, tiny....@gmail.com, vba...@suse.cz, wal...@google.com, wi...@infradead.org, yang...@linux.alibaba.com
On Sun, 13 Oct 2019 20:10:06 -0700 syzbot <syzbot+3370fc...@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 <richar...@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 <richar...@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.162...@linux.intel.com
Signed-off-by: Wei Yang <richar...@linux.intel.com>
Acked-by: Konstantin Khlebnikov <khleb...@yandex-team.ru>
Cc: Kirill A. Shutemov <kirill....@linux.intel.com>
Cc: "Jérôme Glisse" <jgl...@redhat.com>
Cc: Mike Kravetz <mike.k...@oracle.com>
Cc: Rik van Riel <ri...@surriel.com>
Cc: Qian Cai <c...@lca.pw>
Cc: Shakeel Butt <shak...@google.com>
Signed-off-by: Andrew Morton <ak...@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;
_

Eric Biggers

unread,
Oct 25, 2019, 11:41:34 AM10/25/19
to syzbot, syzkall...@googlegroups.com
#syz invalid
Reply all
Reply to author
Forward
0 new messages