* mm: kernel BUG at mm/huge_memory.c:2785! @ 2014-02-27 13:35 Sasha Levin 2014-02-27 15:03 ` Kirill A. Shutemov 0 siblings, 1 reply; 10+ messages in thread From: Sasha Levin @ 2014-02-27 13:35 UTC (permalink / raw) To: linux-mm@kvack.org; +Cc: Andrew Morton, LKML, Kirill A. Shutemov Hi all, While fuzzing with trinity inside a KVM tools guest running latest -next kernel I've stumbled on the following spew: [ 1428.146261] kernel BUG at mm/huge_memory.c:2785! [ 1428.147100] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 1428.148512] Dumping ftrace buffer: [ 1428.149497] (ftrace buffer empty) [ 1428.150248] Modules linked in: [ 1428.151164] CPU: 106 PID: 29430 Comm: trinity-c106 Tainted: G W 3.14.0-rc4-next-20140226-sasha-00013-g082bdac-dirty #4 [ 1428.153515] task: ffff8808906c8000 ti: ffff880890aa6000 task.ti: ffff880890aa6000 [ 1428.154274] RIP: 0010:[<mm/huge_memory.c:2785>] [<mm/huge_memory.c:2785>] __split_huge_page_pmd+0x3f/0x2e0 [ 1428.154274] RSP: 0018:ffff880890aa7c98 EFLAGS: 00010287 [ 1428.154274] RAX: ffff880890f34000 RBX: ffff880b3c6791a0 RCX: 00003ffffffff000 [ 1428.154274] RDX: ffff880b3c6791a0 RSI: 00007f29869b4000 RDI: ffff8803dcbd6400 [ 1428.154274] RBP: ffff880890aa7ce8 R08: 00007f29869b5000 R09: 0000000000000000 [ 1428.154274] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880b3c6791a0 [ 1428.154274] R13: 00007f2986800000 R14: ffff8803dcbd6400 R15: 00007f29869b4fff [ 1428.154274] FS: 00007f298bb67700(0000) GS:ffff8803de800000(0000) knlGS:0000000000000000 [ 1428.154274] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 1428.154274] CR2: 00007f298b978608 CR3: 00000008907c3000 CR4: 00000000000006e0 [ 1428.154274] DR0: 8200000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1428.154274] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600 [ 1428.154274] Stack: [ 1428.154274] 00000000001d8400 0000000000000001 ffff880890aa7cc8 ffff880890f34000 [ 1428.154274] ffffffff876bcfe0 ffff880b3c6791a0 00007f29869b4000 00007f29869b5000 [ 1428.154274] ffff880890aa7e18 00007f29869b4fff ffff880890aa7d78 ffffffff8127ff06 [ 1428.154274] Call Trace: [ 1428.154274] [<mm/memory.c:1230 mm/memory.c:1265 mm/memory.c:1290>] unmap_page_range+0x2a6/0x410 [ 1428.154274] [<mm/memory.c:1338>] unmap_single_vma+0xf1/0x110 [ 1428.154274] [<mm/memory.c:1365>] unmap_vmas+0x61/0xa0 [ 1428.154274] [<mm/mmap.c:2361>] unmap_region+0xbc/0x120 [ 1428.154274] [<include/linux/mm.h:1315 mm/mmap.c:2332 mm/mmap.c:2557>] do_munmap+0x27a/0x350 [ 1428.154274] [<mm/mmap.c:2568>] ? vm_munmap+0x41/0x80 [ 1428.154274] [<mm/mmap.c:2569>] vm_munmap+0x4f/0x80 [ 1428.154274] [<mm/mmap.c:2574>] SyS_munmap+0x27/0x40 [ 1428.154274] [<arch/x86/kernel/entry_64.S:749>] tracesys+0xdd/0xe2 [ 1428.154274] Code: e5 00 00 e0 ff 53 49 89 d4 48 83 ec 28 48 8b 47 40 48 89 45 c8 4c 3b 2f 72 11 49 8d 95 00 00 20 00 48 89 55 c0 48 39 57 08 73 11 <0f> 0b 0f 1f 80 00 00 00 00 eb fe 66 0f 1f 44 00 00 4c 89 e3 49 [ 1428.154274] RIP [<mm/huge_memory.c:2785>] __split_huge_page_pmd+0x3f/0x2e0 [ 1428.154274] RSP <ffff880890aa7c98> Thanks, Sasha -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: mm: kernel BUG at mm/huge_memory.c:2785! 2014-02-27 13:35 mm: kernel BUG at mm/huge_memory.c:2785! Sasha Levin @ 2014-02-27 15:03 ` Kirill A. Shutemov 2014-03-04 23:57 ` Sasha Levin 2014-03-05 3:16 ` Bob Liu 0 siblings, 2 replies; 10+ messages in thread From: Kirill A. Shutemov @ 2014-02-27 15:03 UTC (permalink / raw) To: Sasha Levin, Andrea Arcangeli Cc: linux-mm@kvack.org, Andrew Morton, LKML, Kirill A. Shutemov Sasha Levin wrote: > Hi all, > > While fuzzing with trinity inside a KVM tools guest running latest -next kernel I've stumbled on the > following spew: > > [ 1428.146261] kernel BUG at mm/huge_memory.c:2785! Hm, interesting. It seems we either failed to split huge page on vma split or it materialized from under us. I don't see how it can happen: - it seems we do the right thing with vma_adjust_trans_huge() in __split_vma(); - we hold ->mmap_sem all the way from vm_munmap(). At least I don't see a place where we could drop it; Andrea, any ideas? > [ 1428.147100] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC > [ 1428.148512] Dumping ftrace buffer: > [ 1428.149497] (ftrace buffer empty) > [ 1428.150248] Modules linked in: > [ 1428.151164] CPU: 106 PID: 29430 Comm: trinity-c106 Tainted: G W > 3.14.0-rc4-next-20140226-sasha-00013-g082bdac-dirty #4 > [ 1428.153515] task: ffff8808906c8000 ti: ffff880890aa6000 task.ti: ffff880890aa6000 > [ 1428.154274] RIP: 0010:[<mm/huge_memory.c:2785>] [<mm/huge_memory.c:2785>] > __split_huge_page_pmd+0x3f/0x2e0 > [ 1428.154274] RSP: 0018:ffff880890aa7c98 EFLAGS: 00010287 > [ 1428.154274] RAX: ffff880890f34000 RBX: ffff880b3c6791a0 RCX: 00003ffffffff000 > [ 1428.154274] RDX: ffff880b3c6791a0 RSI: 00007f29869b4000 RDI: ffff8803dcbd6400 > [ 1428.154274] RBP: ffff880890aa7ce8 R08: 00007f29869b5000 R09: 0000000000000000 > [ 1428.154274] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880b3c6791a0 > [ 1428.154274] R13: 00007f2986800000 R14: ffff8803dcbd6400 R15: 00007f29869b4fff > [ 1428.154274] FS: 00007f298bb67700(0000) GS:ffff8803de800000(0000) knlGS:0000000000000000 > [ 1428.154274] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > [ 1428.154274] CR2: 00007f298b978608 CR3: 00000008907c3000 CR4: 00000000000006e0 > [ 1428.154274] DR0: 8200000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 1428.154274] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600 > [ 1428.154274] Stack: > [ 1428.154274] 00000000001d8400 0000000000000001 ffff880890aa7cc8 ffff880890f34000 > [ 1428.154274] ffffffff876bcfe0 ffff880b3c6791a0 00007f29869b4000 00007f29869b5000 > [ 1428.154274] ffff880890aa7e18 00007f29869b4fff ffff880890aa7d78 ffffffff8127ff06 > [ 1428.154274] Call Trace: > [ 1428.154274] [<mm/memory.c:1230 mm/memory.c:1265 mm/memory.c:1290>] unmap_page_range+0x2a6/0x410 > [ 1428.154274] [<mm/memory.c:1338>] unmap_single_vma+0xf1/0x110 > [ 1428.154274] [<mm/memory.c:1365>] unmap_vmas+0x61/0xa0 > [ 1428.154274] [<mm/mmap.c:2361>] unmap_region+0xbc/0x120 > [ 1428.154274] [<include/linux/mm.h:1315 mm/mmap.c:2332 mm/mmap.c:2557>] do_munmap+0x27a/0x350 > [ 1428.154274] [<mm/mmap.c:2568>] ? vm_munmap+0x41/0x80 > [ 1428.154274] [<mm/mmap.c:2569>] vm_munmap+0x4f/0x80 > [ 1428.154274] [<mm/mmap.c:2574>] SyS_munmap+0x27/0x40 > [ 1428.154274] [<arch/x86/kernel/entry_64.S:749>] tracesys+0xdd/0xe2 > [ 1428.154274] Code: e5 00 00 e0 ff 53 49 89 d4 48 83 ec 28 48 8b 47 40 48 89 45 c8 4c 3b 2f 72 11 > 49 8d 95 00 00 20 00 48 89 55 c0 48 39 57 08 73 11 <0f> 0b 0f 1f 80 00 00 00 00 eb fe 66 0f 1f 44 00 > 00 4c 89 e3 49 > [ 1428.154274] RIP [<mm/huge_memory.c:2785>] __split_huge_page_pmd+0x3f/0x2e0 > [ 1428.154274] RSP <ffff880890aa7c98> > > > Thanks, > Sasha -- Kirill A. Shutemov -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mm: kernel BUG at mm/huge_memory.c:2785! 2014-02-27 15:03 ` Kirill A. Shutemov @ 2014-03-04 23:57 ` Sasha Levin 2014-03-05 13:52 ` Kirill A. Shutemov 2014-03-05 3:16 ` Bob Liu 1 sibling, 1 reply; 10+ messages in thread From: Sasha Levin @ 2014-03-04 23:57 UTC (permalink / raw) To: Kirill A. Shutemov, Andrea Arcangeli Cc: linux-mm@kvack.org, Andrew Morton, LKML On 02/27/2014 10:03 AM, Kirill A. Shutemov wrote: > Sasha Levin wrote: >> >Hi all, >> > >> >While fuzzing with trinity inside a KVM tools guest running latest -next kernel I've stumbled on the >> >following spew: >> > >> >[ 1428.146261] kernel BUG at mm/huge_memory.c:2785! > Hm, interesting. > > It seems we either failed to split huge page on vma split or it > materialized from under us. I don't see how it can happen: > > - it seems we do the right thing with vma_adjust_trans_huge() in > __split_vma(); > - we hold ->mmap_sem all the way from vm_munmap(). At least I don't see > a place where we could drop it; > > Andrea, any ideas? And a somewhat related issue (please correct me if I'm wrong): [ 2208.713223] kernel BUG at mm/mlock.c:528! [ 2208.713692] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 2208.714488] Dumping ftrace buffer: [ 2208.715209] (ftrace buffer empty) [ 2208.715759] Modules linked in: [ 2208.716206] CPU: 34 PID: 3736 Comm: trinity-c209 Tainted: G W 3.14.0-rc5-next-20140304-sasha-00009-geaa4df0 #77 [ 2208.717637] task: ffff880ff90c8000 ti: ffff880ff90c6000 task.ti: ffff880ff90c6000 [ 2208.718742] RIP: 0010:[<ffffffff812a53d6>] [<ffffffff812a53d6>] munlock_vma_pages_range+0x176/0x1d0 [ 2208.720107] RSP: 0018:ffff880ff90c7e08 EFLAGS: 00010206 [ 2208.720711] RAX: 00000000000001ff RBX: 000000000003f000 RCX: 0000000000000000 [ 2208.721456] RDX: 000000000000003f RSI: ffffffff8129d92d RDI: ffffffff84476115 [ 2208.721456] RBP: ffff880ff90c7ec8 R08: 0000000000000000 R09: 0000000000000000 [ 2208.721456] R10: 0000000000000001 R11: 0000000000000000 R12: fffffffffffffff2 [ 2208.721456] R13: ffff880313b41600 R14: 0000000000040000 R15: ffff880ff90c7e94 [ 2208.721456] FS: 00007f2bd5330700(0000) GS:ffff88032bc00000(0000) knlGS:0000000000000000 [ 2208.721456] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 2208.721456] CR2: 0000000002767c90 CR3: 0000000ffa1d4000 CR4: 00000000000006e0 [ 2208.721456] DR0: 00007f15fe555000 DR1: 0000000000000000 DR2: 0000000000000000 [ 2208.721456] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600 [ 2208.721456] Stack: [ 2208.721456] 0000000000000000 0000000000000000 0001880ff90c7e38 0000000000000000 [ 2208.721456] 0000000000000000 ffff880313b41600 00000000f90c7e88 0000000000000000 [ 2208.721456] 00ff880ff90c7e58 ffff880815e8cba0 ffff880ff90c7eb8 ffff880313b41600 [ 2208.721456] Call Trace: [ 2208.721456] [<ffffffff812a8a52>] do_munmap+0x1d2/0x350 [ 2208.721456] [<ffffffff84473eb6>] ? down_write+0xa6/0xc0 [ 2208.721456] [<ffffffff812a8c16>] ? vm_munmap+0x46/0x80 [ 2208.721456] [<ffffffff812a8c24>] vm_munmap+0x54/0x80 [ 2208.721456] [<ffffffff812a8c7c>] SyS_munmap+0x2c/0x40 [ 2208.721456] [<ffffffff84480110>] tracesys+0xdd/0xe2 [ 2208.721456] Code: fd ff ff 4c 89 e6 48 89 c3 48 8d bd 40 ff ff ff e8 80 fa ff ff eb 2f 66 0f 1f 44 00 00 8b 45 cc 48 89 da 48 c1 ea 0c 85 d0 74 12 <0f> 0b 0f 1f 84 00 00 00 00 00 eb fe 66 0f 1f 44 00 00 ff c0 48 [ 2208.721456] RIP [<ffffffff812a53d6>] munlock_vma_pages_range+0x176/0x1d0 [ 2208.721456] RSP <ffff880ff90c7e08> Thanks, Sasha -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mm: kernel BUG at mm/huge_memory.c:2785! 2014-03-04 23:57 ` Sasha Levin @ 2014-03-05 13:52 ` Kirill A. Shutemov 2014-03-06 4:44 ` Sasha Levin 0 siblings, 1 reply; 10+ messages in thread From: Kirill A. Shutemov @ 2014-03-05 13:52 UTC (permalink / raw) To: Sasha Levin Cc: Kirill A. Shutemov, Andrea Arcangeli, linux-mm@kvack.org, Andrew Morton, LKML Sasha Levin wrote: > On 02/27/2014 10:03 AM, Kirill A. Shutemov wrote: > > Sasha Levin wrote: > >> >Hi all, > >> > > >> >While fuzzing with trinity inside a KVM tools guest running latest -next kernel I've stumbled on the > >> >following spew: > >> > > >> >[ 1428.146261] kernel BUG at mm/huge_memory.c:2785! > > Hm, interesting. > > > > It seems we either failed to split huge page on vma split or it > > materialized from under us. I don't see how it can happen: > > > > - it seems we do the right thing with vma_adjust_trans_huge() in > > __split_vma(); > > - we hold ->mmap_sem all the way from vm_munmap(). At least I don't see > > a place where we could drop it; > > > > Andrea, any ideas? > > And a somewhat related issue (please correct me if I'm wrong): Yeah. Looks similar. And I still have no idea how it could happened. Do you trinity logs for the crash? > > [ 2208.713223] kernel BUG at mm/mlock.c:528! > [ 2208.713692] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC > [ 2208.714488] Dumping ftrace buffer: > [ 2208.715209] (ftrace buffer empty) > [ 2208.715759] Modules linked in: > [ 2208.716206] CPU: 34 PID: 3736 Comm: trinity-c209 Tainted: G W 3.14.0-rc5-next-20140304-sasha-00009-geaa4df0 #77 > [ 2208.717637] task: ffff880ff90c8000 ti: ffff880ff90c6000 task.ti: ffff880ff90c6000 > [ 2208.718742] RIP: 0010:[<ffffffff812a53d6>] [<ffffffff812a53d6>] munlock_vma_pages_range+0x176/0x1d0 > [ 2208.720107] RSP: 0018:ffff880ff90c7e08 EFLAGS: 00010206 > [ 2208.720711] RAX: 00000000000001ff RBX: 000000000003f000 RCX: 0000000000000000 > [ 2208.721456] RDX: 000000000000003f RSI: ffffffff8129d92d RDI: ffffffff84476115 > [ 2208.721456] RBP: ffff880ff90c7ec8 R08: 0000000000000000 R09: 0000000000000000 > [ 2208.721456] R10: 0000000000000001 R11: 0000000000000000 R12: fffffffffffffff2 > [ 2208.721456] R13: ffff880313b41600 R14: 0000000000040000 R15: ffff880ff90c7e94 > [ 2208.721456] FS: 00007f2bd5330700(0000) GS:ffff88032bc00000(0000) knlGS:0000000000000000 > [ 2208.721456] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > [ 2208.721456] CR2: 0000000002767c90 CR3: 0000000ffa1d4000 CR4: 00000000000006e0 > [ 2208.721456] DR0: 00007f15fe555000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 2208.721456] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600 > [ 2208.721456] Stack: > [ 2208.721456] 0000000000000000 0000000000000000 0001880ff90c7e38 0000000000000000 > [ 2208.721456] 0000000000000000 ffff880313b41600 00000000f90c7e88 0000000000000000 > [ 2208.721456] 00ff880ff90c7e58 ffff880815e8cba0 ffff880ff90c7eb8 ffff880313b41600 > [ 2208.721456] Call Trace: > [ 2208.721456] [<ffffffff812a8a52>] do_munmap+0x1d2/0x350 > [ 2208.721456] [<ffffffff84473eb6>] ? down_write+0xa6/0xc0 > [ 2208.721456] [<ffffffff812a8c16>] ? vm_munmap+0x46/0x80 > [ 2208.721456] [<ffffffff812a8c24>] vm_munmap+0x54/0x80 > [ 2208.721456] [<ffffffff812a8c7c>] SyS_munmap+0x2c/0x40 > [ 2208.721456] [<ffffffff84480110>] tracesys+0xdd/0xe2 > [ 2208.721456] Code: fd ff ff 4c 89 e6 48 89 c3 48 8d bd 40 ff ff ff e8 80 fa ff ff eb 2f 66 0f 1f 44 00 00 8b 45 cc 48 89 da 48 c1 ea 0c 85 d0 74 12 <0f> 0b 0f 1f 84 00 00 00 00 00 eb fe 66 0f 1f 44 00 00 ff c0 48 > [ 2208.721456] RIP [<ffffffff812a53d6>] munlock_vma_pages_range+0x176/0x1d0 > [ 2208.721456] RSP <ffff880ff90c7e08> > > > Thanks, > Sasha -- Kirill A. Shutemov -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mm: kernel BUG at mm/huge_memory.c:2785! 2014-03-05 13:52 ` Kirill A. Shutemov @ 2014-03-06 4:44 ` Sasha Levin 0 siblings, 0 replies; 10+ messages in thread From: Sasha Levin @ 2014-03-06 4:44 UTC (permalink / raw) To: Kirill A. Shutemov Cc: Andrea Arcangeli, linux-mm@kvack.org, Andrew Morton, LKML On 03/05/2014 08:52 AM, Kirill A. Shutemov wrote: > Sasha Levin wrote: >> On 02/27/2014 10:03 AM, Kirill A. Shutemov wrote: >>> Sasha Levin wrote: >>>>> Hi all, >>>>> >>>>> While fuzzing with trinity inside a KVM tools guest running latest -next kernel I've stumbled on the >>>>> following spew: >>>>> >>>>> [ 1428.146261] kernel BUG at mm/huge_memory.c:2785! >>> Hm, interesting. >>> >>> It seems we either failed to split huge page on vma split or it >>> materialized from under us. I don't see how it can happen: >>> >>> - it seems we do the right thing with vma_adjust_trans_huge() in >>> __split_vma(); >>> - we hold ->mmap_sem all the way from vm_munmap(). At least I don't see >>> a place where we could drop it; >>> >>> Andrea, any ideas? >> >> And a somewhat related issue (please correct me if I'm wrong): > > Yeah. Looks similar. And I still have no idea how it could happened. > > Do you trinity logs for the crash? I can't get it to reproduce with trinity logging enabled, I guess it makes it harder for the race to occur. I'll keep it running through the night but don't really have high hopes. Thanks, Sasha -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mm: kernel BUG at mm/huge_memory.c:2785! 2014-02-27 15:03 ` Kirill A. Shutemov 2014-03-04 23:57 ` Sasha Levin @ 2014-03-05 3:16 ` Bob Liu 2014-03-05 3:53 ` Sasha Levin 1 sibling, 1 reply; 10+ messages in thread From: Bob Liu @ 2014-03-05 3:16 UTC (permalink / raw) To: Kirill A. Shutemov Cc: Sasha Levin, Andrea Arcangeli, linux-mm@kvack.org, Andrew Morton, LKML On Thu, Feb 27, 2014 at 11:03 PM, Kirill A. Shutemov <kirill.shutemov@linux.intel.com> wrote: > Sasha Levin wrote: >> Hi all, >> >> While fuzzing with trinity inside a KVM tools guest running latest -next kernel I've stumbled on the >> following spew: >> >> [ 1428.146261] kernel BUG at mm/huge_memory.c:2785! > > Hm, interesting. > > It seems we either failed to split huge page on vma split or it > materialized from under us. I don't see how it can happen: > > - it seems we do the right thing with vma_adjust_trans_huge() in > __split_vma(); > - we hold ->mmap_sem all the way from vm_munmap(). At least I don't see > a place where we could drop it; > Enable CONFIG_DEBUG_VM may show some useful information, at least we can confirm weather rwsem_is_locked(&tlb->mm->mmap_sem) before split_huge_page_pmd(). -- Regards, --Bob -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mm: kernel BUG at mm/huge_memory.c:2785! 2014-03-05 3:16 ` Bob Liu @ 2014-03-05 3:53 ` Sasha Levin 2014-03-07 1:32 ` Sasha Levin 0 siblings, 1 reply; 10+ messages in thread From: Sasha Levin @ 2014-03-05 3:53 UTC (permalink / raw) To: Bob Liu, Kirill A. Shutemov Cc: Andrea Arcangeli, linux-mm@kvack.org, Andrew Morton, LKML On 03/04/2014 10:16 PM, Bob Liu wrote: > On Thu, Feb 27, 2014 at 11:03 PM, Kirill A. Shutemov > <kirill.shutemov@linux.intel.com> wrote: >> Sasha Levin wrote: >>> Hi all, >>> >>> While fuzzing with trinity inside a KVM tools guest running latest -next kernel I've stumbled on the >>> following spew: >>> >>> [ 1428.146261] kernel BUG at mm/huge_memory.c:2785! >> >> Hm, interesting. >> >> It seems we either failed to split huge page on vma split or it >> materialized from under us. I don't see how it can happen: >> >> - it seems we do the right thing with vma_adjust_trans_huge() in >> __split_vma(); >> - we hold ->mmap_sem all the way from vm_munmap(). At least I don't see >> a place where we could drop it; >> > > Enable CONFIG_DEBUG_VM may show some useful information, at least we > can confirm weather rwsem_is_locked(&tlb->mm->mmap_sem) before > split_huge_page_pmd(). I have CONFIG_DEBUG_VM enabled and that code you're talking is not triggering, so mmap_sem is locked. Thanks, Sasha -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mm: kernel BUG at mm/huge_memory.c:2785! 2014-03-05 3:53 ` Sasha Levin @ 2014-03-07 1:32 ` Sasha Levin 2014-03-07 12:18 ` Kirill A. Shutemov 0 siblings, 1 reply; 10+ messages in thread From: Sasha Levin @ 2014-03-07 1:32 UTC (permalink / raw) To: Bob Liu, Kirill A. Shutemov Cc: Andrea Arcangeli, linux-mm@kvack.org, Andrew Morton, LKML On 03/04/2014 10:53 PM, Sasha Levin wrote: > On 03/04/2014 10:16 PM, Bob Liu wrote: >> On Thu, Feb 27, 2014 at 11:03 PM, Kirill A. Shutemov >> <kirill.shutemov@linux.intel.com> wrote: >>> Sasha Levin wrote: >>>> Hi all, >>>> >>>> While fuzzing with trinity inside a KVM tools guest running latest -next kernel I've stumbled on the >>>> following spew: >>>> >>>> [ 1428.146261] kernel BUG at mm/huge_memory.c:2785! >>> >>> Hm, interesting. >>> >>> It seems we either failed to split huge page on vma split or it >>> materialized from under us. I don't see how it can happen: >>> >>> - it seems we do the right thing with vma_adjust_trans_huge() in >>> __split_vma(); >>> - we hold ->mmap_sem all the way from vm_munmap(). At least I don't see >>> a place where we could drop it; >>> >> >> Enable CONFIG_DEBUG_VM may show some useful information, at least we >> can confirm weather rwsem_is_locked(&tlb->mm->mmap_sem) before >> split_huge_page_pmd(). > > I have CONFIG_DEBUG_VM enabled and that code you're talking is not triggering, so mmap_sem > is locked. Guess what. I've just hit it. It's worth keeping in mind that this is the first time I see it. [ 695.173659] kernel BUG at mm/memory.c:1228! [ 695.174233] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 695.175322] Dumping ftrace buffer: [ 695.176180] (ftrace buffer empty) [ 695.176813] Modules linked in: [ 695.177223] CPU: 6 PID: 21524 Comm: trinity-c362 Tainted: G W 3.14.0-rc5-next-20140305-sasha-00012-g00c5c8f-dirty #110 [ 695.179249] task: ffff880d27a70000 ti: ffff880c28042000 task.ti: ffff880c28042000 [ 695.180341] RIP: 0010:[<ffffffff8129f82c>] [<ffffffff8129f82c>] unmap_page_range+0x25c/0x410 [ 695.180341] RSP: 0000:ffff880c28043b18 EFLAGS: 00010292 [ 695.180341] RAX: 0000000000000083 RBX: ffff880528fca698 RCX: 0000000000000000 [ 695.180341] RDX: ffff880d27a70000 RSI: 0000000000000001 RDI: 0000000000000282 [ 695.180341] RBP: ffff880c28043b98 R08: 0000000000000001 R09: 0000000000000001 [ 695.180341] R10: 0000000000000001 R11: 0000000000000001 R12: 00007f735a600000 [ 695.180341] R13: 00007f735a633000 R14: ffff880c28043c38 R15: 00007f735a632fff [ 695.180341] FS: 0000000000000000(0000) GS:ffff88072b800000(0000) knlGS:0000000000000000 [ 695.180341] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 695.180341] CR2: 0000000000000008 CR3: 0000000005e27000 CR4: 00000000000006a0 [ 695.180341] DR0: 000000000089e000 DR1: 0000000000000000 DR2: 0000000000000000 [ 695.180341] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600 [ 695.180341] Stack: [ 695.180341] ffffffff8447a29d 00007f735a600000 00007f735a632fff 00007f735a633000 [ 695.180341] ffff880c285087f0 0000000000000000 00007f735a632fff ffff88081804bc00 [ 695.180341] ffff880505918e68 00007f735a633000 ffff880c27f745c0 ffff88081804bc00 [ 695.180341] Call Trace: [ 695.180341] [<ffffffff8447a29d>] ? _raw_spin_unlock_irqrestore+0x6d/0xc0 [ 695.180341] [<ffffffff8129fae1>] unmap_single_vma+0x101/0x120 [ 695.180341] [<ffffffff8129fb61>] unmap_vmas+0x61/0xa0 [ 695.180341] [<ffffffff812a6f20>] exit_mmap+0xd0/0x170 [ 695.180341] [<ffffffff812ddbc0>] ? __khugepaged_exit+0xe0/0x150 [ 695.180341] [<ffffffff8114030c>] mmput+0x7c/0xf0 [ 695.180341] [<ffffffff8114451d>] exit_mm+0x18d/0x1a0 [ 695.180341] [<ffffffff811f7fe5>] ? acct_collect+0x175/0x1b0 [ 695.180341] [<ffffffff8114696f>] do_exit+0x26f/0x520 [ 695.180341] [<ffffffff81146cc9>] do_group_exit+0xa9/0xe0 [ 695.180341] [<ffffffff8115c562>] get_signal_to_deliver+0x4e2/0x570 [ 695.180341] [<ffffffff8106fc3b>] do_signal+0x4b/0x120 [ 695.180341] [<ffffffff8118ab06>] ? vtime_account_user+0x96/0xb0 [ 695.180341] [<ffffffff811a0000>] ? print_cfs_group_stats+0x570/0x900 [ 695.180341] [<ffffffff810c25b5>] ? __bad_area_nosemaphore+0x45/0x250 [ 695.180341] [<ffffffff81269545>] ? context_tracking_user_exit+0x195/0x1d0 [ 695.180341] [<ffffffff81269545>] ? context_tracking_user_exit+0x195/0x1d0 [ 695.180341] [<ffffffff811ab7dd>] ? trace_hardirqs_on+0xd/0x10 [ 695.180341] [<ffffffff8106ff8a>] do_notify_resume+0x5a/0xe0 [ 695.180341] [<ffffffff8447a93b>] retint_signal+0x4d/0x92 [ 695.180341] Code: 00 00 00 75 32 48 8b 45 b8 4c 89 e9 4c 8b 48 08 4c 8b 00 4c 89 e2 48 c7 c6 38 0c 66 84 48 c7 c7 10 d5 6c 85 31 c0 e8 70 2f 1d 03 <0f> 0b 66 90 eb fe 66 0f 1f 44 00 00 48 8b 3b 48 83 3d cd e1 ba [ 695.180341] RIP [<ffffffff8129f82c>] unmap_page_range+0x25c/0x410 [ 695.180341] RSP <ffff880c28043b18> Thanks, Sasha -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mm: kernel BUG at mm/huge_memory.c:2785! 2014-03-07 1:32 ` Sasha Levin @ 2014-03-07 12:18 ` Kirill A. Shutemov 2014-03-14 20:42 ` Sasha Levin 0 siblings, 1 reply; 10+ messages in thread From: Kirill A. Shutemov @ 2014-03-07 12:18 UTC (permalink / raw) To: Sasha Levin Cc: Bob Liu, Kirill A. Shutemov, Andrea Arcangeli, linux-mm@kvack.org, Andrew Morton, LKML On Thu, Mar 06, 2014 at 08:32:48PM -0500, Sasha Levin wrote: > On 03/04/2014 10:53 PM, Sasha Levin wrote: > >On 03/04/2014 10:16 PM, Bob Liu wrote: > >>On Thu, Feb 27, 2014 at 11:03 PM, Kirill A. Shutemov > >><kirill.shutemov@linux.intel.com> wrote: > >>>Sasha Levin wrote: > >>>>Hi all, > >>>> > >>>>While fuzzing with trinity inside a KVM tools guest running latest -next kernel I've stumbled on the > >>>>following spew: > >>>> > >>>>[ 1428.146261] kernel BUG at mm/huge_memory.c:2785! > >>> > >>>Hm, interesting. > >>> > >>>It seems we either failed to split huge page on vma split or it > >>>materialized from under us. I don't see how it can happen: > >>> > >>> - it seems we do the right thing with vma_adjust_trans_huge() in > >>> __split_vma(); > >>> - we hold ->mmap_sem all the way from vm_munmap(). At least I don't see > >>> a place where we could drop it; > >>> > >> > >>Enable CONFIG_DEBUG_VM may show some useful information, at least we > >>can confirm weather rwsem_is_locked(&tlb->mm->mmap_sem) before > >>split_huge_page_pmd(). > > > >I have CONFIG_DEBUG_VM enabled and that code you're talking is not triggering, so mmap_sem > >is locked. > > Guess what. I've just hit it. I think this particular traceback is not a real problem: by time of exit_mm() we shouldn't race with anybody for the mm_struct. We probably could drop ->mmap_sem later in mmput() rather then in exit_mm() to fix this false positive. > It's worth keeping in mind that this is the first time I see it. Hm. That's strange exit_mmap() is called without holding ->mmap_sem. -- Kirill A. Shutemov -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mm: kernel BUG at mm/huge_memory.c:2785! 2014-03-07 12:18 ` Kirill A. Shutemov @ 2014-03-14 20:42 ` Sasha Levin 0 siblings, 0 replies; 10+ messages in thread From: Sasha Levin @ 2014-03-14 20:42 UTC (permalink / raw) To: Kirill A. Shutemov Cc: Bob Liu, Kirill A. Shutemov, Andrea Arcangeli, linux-mm@kvack.org, Andrew Morton, LKML On 03/07/2014 07:18 AM, Kirill A. Shutemov wrote: > On Thu, Mar 06, 2014 at 08:32:48PM -0500, Sasha Levin wrote: >> On 03/04/2014 10:53 PM, Sasha Levin wrote: >>> On 03/04/2014 10:16 PM, Bob Liu wrote: >>>> On Thu, Feb 27, 2014 at 11:03 PM, Kirill A. Shutemov >>>> <kirill.shutemov@linux.intel.com> wrote: >>>>> Sasha Levin wrote: >>>>>> Hi all, >>>>>> >>>>>> While fuzzing with trinity inside a KVM tools guest running latest -next kernel I've stumbled on the >>>>>> following spew: >>>>>> >>>>>> [ 1428.146261] kernel BUG at mm/huge_memory.c:2785! >>>>> >>>>> Hm, interesting. >>>>> >>>>> It seems we either failed to split huge page on vma split or it >>>>> materialized from under us. I don't see how it can happen: >>>>> >>>>> - it seems we do the right thing with vma_adjust_trans_huge() in >>>>> __split_vma(); >>>>> - we hold ->mmap_sem all the way from vm_munmap(). At least I don't see >>>>> a place where we could drop it; >>>>> >>>> >>>> Enable CONFIG_DEBUG_VM may show some useful information, at least we >>>> can confirm weather rwsem_is_locked(&tlb->mm->mmap_sem) before >>>> split_huge_page_pmd(). >>> >>> I have CONFIG_DEBUG_VM enabled and that code you're talking is not triggering, so mmap_sem >>> is locked. >> >> Guess what. I've just hit it. > > I think this particular traceback is not a real problem: by time of > exit_mm() we shouldn't race with anybody for the mm_struct. > > We probably could drop ->mmap_sem later in mmput() rather then in > exit_mm() to fix this false positive. > >> It's worth keeping in mind that this is the first time I see it. > > Hm. That's strange exit_mmap() is called without holding ->mmap_sem. > This issues does happen quite often and is very easy to reproduce, I could try anything you can thing of. Thanks, Sasha -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2014-03-14 20:42 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-02-27 13:35 mm: kernel BUG at mm/huge_memory.c:2785! Sasha Levin 2014-02-27 15:03 ` Kirill A. Shutemov 2014-03-04 23:57 ` Sasha Levin 2014-03-05 13:52 ` Kirill A. Shutemov 2014-03-06 4:44 ` Sasha Levin 2014-03-05 3:16 ` Bob Liu 2014-03-05 3:53 ` Sasha Levin 2014-03-07 1:32 ` Sasha Levin 2014-03-07 12:18 ` Kirill A. Shutemov 2014-03-14 20:42 ` Sasha Levin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).