mm: kernel BUG at mm/huge_memory.c:1440!

Hi all,

While fuzzing with trinity inside a KVM tools guest running latest -next kernel, I've stumbled on the following spew.

	page = pmd_page(orig_pmd);
	page_remove_rmap(page);
	VM_BUG_ON(page_mapcount(page) < 0);
	add_mm_counter(tlb->mm, MM_ANONPAGES, -HPAGE_PMD_NR);
	VM_BUG_ON(!PageHead(page));		<=== HERE
	atomic_long_dec(&tlb->mm->nr_ptes);
	spin_unlock(ptl);
	tlb_remove_page(tlb, page);

[  265.474585] kernel BUG at mm/huge_memory.c:1440!
[  265.475129] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[  265.476684] Dumping ftrace buffer:
[  265.477144]    (ftrace buffer empty)
[  265.478398] Modules linked in:
[  265.478807] CPU: 8 PID: 11344 Comm: trinity-c206 Tainted: G        W    3.13.0-rc5-ne
xt-20131223-sasha-00015-gec22156-dirty #8
[  265.480172] task: ffff8801cb573000 ti: ffff8801cbd3a000 task.ti: ffff8801cbd3a000
[  265.480172] RIP: 0010:[<ffffffff812c7f70>]  [<ffffffff812c7f70>] zap_huge_pmd+0x170/0
x1f0
[  265.480172] RSP: 0000:ffff8801cbd3bc78  EFLAGS: 00010246
[  265.480172] RAX: 015fffff80090018 RBX: ffff8801cbd3bde8 RCX: ffffffffffffff9c
[  265.480172] RDX: ffffffffffffffff RSI: 0000000000000008 RDI: ffff8800bffd2000
[  265.480172] RBP: ffff8801cbd3bcb8 R08: 0000000000000000 R09: 0000000000000000
[  265.480172] R10: 0000000000000001 R11: 0000000000000000 R12: ffffea0002856740
[  265.480172] R13: ffffea0002d50000 R14: 00007ff915000000 R15: 00007ff930e48fff
[  265.480172] FS:  00007ff934899700(0000) GS:ffff88014d400000(0000) knlGS:0000000000000
000
[  265.480172] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  265.480172] CR2: 00007ff93428a000 CR3: 000000010babe000 CR4: 00000000000006e0
[  265.480172] Stack:
[  265.480172]  00000000000004dd ffff8801ccbfbb60 ffff8801cbd3bcb8 ffff8801cbb15540
[  265.480172]  00007ff915000000 00007ff930e49000 ffff8801cbd3bde8 00007ff930e48fff
[  265.480172]  ffff8801cbd3bd48 ffffffff812885b6 ffff88005f5d20c0 00007ff915200000
[  265.480172] Call Trace:
[  265.480172]  [<ffffffff812885b6>] unmap_page_range+0x2c6/0x410
[  265.480172]  [<ffffffff81288801>] unmap_single_vma+0x101/0x120
[  265.480172]  [<ffffffff81288881>] unmap_vmas+0x61/0xa0
[  265.480172]  [<ffffffff8128f730>] exit_mmap+0xd0/0x170
[  265.480172]  [<ffffffff81138860>] mmput+0x70/0xe0
[  265.480172]  [<ffffffff8113c89d>] exit_mm+0x18d/0x1a0
[  265.480172]  [<ffffffff811ea355>] ? acct_collect+0x175/0x1b0
[  265.480172]  [<ffffffff8113ed0f>] do_exit+0x26f/0x520
[  265.480172]  [<ffffffff8113f069>] do_group_exit+0xa9/0xe0
[  265.480172]  [<ffffffff8113f0b7>] SyS_exit_group+0x17/0x20
[  265.480172]  [<ffffffff845f10d0>] tracesys+0xdd/0xe2
[  265.480172] Code: 0f 0b 66 0f 1f 84 00 00 00 00 00 eb fe 66 0f 1f 44 00 00 48 8b 03 f0 48 81 80 50 03 00 00 00 fe ff ff 49 8b 45 00 f6 c4 40 75 10 <0f> 0b 66 0f 1f 44 00 00 eb fe 66 0f 1f 44 00 00 48 8b 03 f0 48
[  265.480172] RIP  [<ffffffff812c7f70>] zap_huge_pmd+0x170/0x1f0
[  265.480172]  RSP <ffff8801cbd3bc78>

Thanks,
Sasha

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Could you dump_page() on the bug?

 Kirill A. Shutemov

Added it in. It doesn't reproduce too easily so it might take a bit.

Thanks,
Sasha

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

[  469.007946] page:ffffea0005bd8000 count:3 mapcount:0 mapping:ffff8800bcd3d171 index: 0x7fca81000
[  469.009362] page flags: 0x2afffff80090018(uptodate|dirty|swapcache|swapbacked)

Thanks,
Sasha

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Ping? It still shows up in 3.13-rc6.

Thanks,
Sasha

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Could you verify if a version before split PMD locks is affected or not? I.e. 3.12 (IIRC)? I've checked if there can be race with THP splitting and it seems there shouldn't be thanks to pmd_lock() protection. So that could be a candidate. Given the recent trinity improvements it would be good to determine if it's a new bug or another years old one...

Thanks,
Vlastimil

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Sorry, I don't have a theory why it can happen. And I can't reproduce it.

Is there chance to get trinity log after the crash?

 Kirill A. Shutemov

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>