Skip to contentSkip to conversation

3.15.0-rc6: VM_BUG_ON_PAGE(PageTail(page), page)

DISCUSSION Dave Jones 4 participants 8 messages May 22, 2014 – May 23, 2014 Memory management

lore
Share & tools
lore

Dave Jones

author
#0 lore raw

Not sure if Sasha has already reported this on -next (It's getting hard to keep track of all the VM bugs he's been finding), but I hit this overnight on .15-rc6. First time I've seen this one.

page:ffffea0004599800 count:0 mapcount:0 mapping: (null) index:0x2
page flags: 0x20000000008000(tail)

------------[ cut here ]------------
kernel BUG at include/linux/page-flags.h:415!
invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
CPU: 1 PID: 6858 Comm: trinity-c42 Not tainted 3.15.0-rc6+ #216
task: ffff88012d18e900 ti: ffff88009e87a000 task.ti: ffff88009e87a000
RIP: 0010:[<ffffffffbb718d98>]  [<ffffffffbb718d98>] PageTransHuge.part.23+0xb/0xd
RSP: 0000:ffff88009e87b940  EFLAGS: 00010246
RAX: 0000000000000001 RBX: 0000000000116660 RCX: 0000000000000006
RDX: 0000000000000000 RSI: ffffffffbb0c00f8 RDI: ffffffffbb0bfed2
RBP: ffff88009e87b940 R08: ffffffffbc01203c R09: 00000000000003da
R10: 00000000000003d9 R11: 0000000000000003 R12: 0000000000000001
R13: 0000000000116800 R14: ffff88024d64ce00 R15: ffffea0004599800
FS:  00007f4fd192e740(0000) GS:ffff88024d040000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000004c00000 CR3: 00000000a19ce000 CR4: 00000000001407e0
DR0: 00000000024f4000 DR1: 0000000001d43000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
Stack:
 ffff88009e87b9e8 ffffffffbb1728a3 ffff88009e87b9e8 ffff88009e87baa8
 ffff88012d18e900 ffff88009e87ba60 0000000000000000 0000000400000016
 0000000000000000 ffff88009e87bfd8 00000000000008b3 ffff88009e87ba50
Call Trace:
 [<ffffffffbb1728a3>] isolate_migratepages_range+0x7a3/0x870
 [<ffffffffbb172d90>] compact_zone+0x370/0x560
 [<ffffffffbb173022>] compact_zone_order+0xa2/0x110
 [<ffffffffbb1733f1>] try_to_compact_pages+0x101/0x130
 [<ffffffffbb71861b>] __alloc_pages_direct_compact+0xac/0x1d0
 [<ffffffffbb15760b>] __alloc_pages_nodemask+0x6ab/0xaf0
 [<ffffffffbb19c9ea>] alloc_pages_vma+0x9a/0x160
 [<ffffffffbb1aef0d>] do_huge_pmd_anonymous_page+0xfd/0x3c0
 [<ffffffffbb0a19cd>] ? get_parent_ip+0xd/0x50
 [<ffffffffbb17ac18>] handle_mm_fault+0x158/0xcb0
 [<ffffffffbb72594d>] ? retint_restore_args+0xe/0xe
 [<ffffffffbb728bb6>] __do_page_fault+0x1a6/0x620
 [<ffffffffbb11011e>] ? __acct_update_integrals+0x8e/0x120
 [<ffffffffbb0a19cd>] ? get_parent_ip+0xd/0x50
 [<ffffffffbb72949b>] ? preempt_count_sub+0x6b/0xf0
 [<ffffffffbb72904e>] do_page_fault+0x1e/0x70
Code: 75 1d 55 be 6c 00 00 00 48 c7 c7 8a 2f a2 bb 48 89 e5 e8 6c 49 95 ff 5d c6 05 74 16 65 00 01 c3 55 31 f6 48 89 e5 e8 28 bd a3 ff <0f> 0b 0f 1f 44 00 00 55 48 89 e5 41 57 45 31 ff 41 56 49 89 fe 

RIP [<ffffffffbb718d98>]

That BUG is..

413 static inline int PageTransHuge(struct page *page) 414 {
415 VM_BUG_ON_PAGE(PageTail(page), page);
416 return PageHead(page);
417 }

--
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>

#1 lore raw
Quoted 48 lines · Dave Jones

Not sure if Sasha has already reported this on -next (It's getting hard to keep track of all the VM bugs he's been finding), but I hit this overnight on .15-rc6. First time I've seen this one.

page:ffffea0004599800 count:0 mapcount:0 mapping: (null) index:0x2
page flags: 0x20000000008000(tail)

------------[ cut here ]------------
kernel BUG at include/linux/page-flags.h:415!
invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
CPU: 1 PID: 6858 Comm: trinity-c42 Not tainted 3.15.0-rc6+ #216
task: ffff88012d18e900 ti: ffff88009e87a000 task.ti: ffff88009e87a000
RIP: 0010:[<ffffffffbb718d98>]  [<ffffffffbb718d98>] PageTransHuge.part.23+0xb/0xd
RSP: 0000:ffff88009e87b940  EFLAGS: 00010246
RAX: 0000000000000001 RBX: 0000000000116660 RCX: 0000000000000006
RDX: 0000000000000000 RSI: ffffffffbb0c00f8 RDI: ffffffffbb0bfed2
RBP: ffff88009e87b940 R08: ffffffffbc01203c R09: 00000000000003da
R10: 00000000000003d9 R11: 0000000000000003 R12: 0000000000000001
R13: 0000000000116800 R14: ffff88024d64ce00 R15: ffffea0004599800
FS:  00007f4fd192e740(0000) GS:ffff88024d040000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000004c00000 CR3: 00000000a19ce000 CR4: 00000000001407e0
DR0: 00000000024f4000 DR1: 0000000001d43000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
Stack:
  ffff88009e87b9e8 ffffffffbb1728a3 ffff88009e87b9e8 ffff88009e87baa8
  ffff88012d18e900 ffff88009e87ba60 0000000000000000 0000000400000016
  0000000000000000 ffff88009e87bfd8 00000000000008b3 ffff88009e87ba50
Call Trace:
  [<ffffffffbb1728a3>] isolate_migratepages_range+0x7a3/0x870
  [<ffffffffbb172d90>] compact_zone+0x370/0x560
  [<ffffffffbb173022>] compact_zone_order+0xa2/0x110
  [<ffffffffbb1733f1>] try_to_compact_pages+0x101/0x130
  [<ffffffffbb71861b>] __alloc_pages_direct_compact+0xac/0x1d0
  [<ffffffffbb15760b>] __alloc_pages_nodemask+0x6ab/0xaf0
  [<ffffffffbb19c9ea>] alloc_pages_vma+0x9a/0x160
  [<ffffffffbb1aef0d>] do_huge_pmd_anonymous_page+0xfd/0x3c0
  [<ffffffffbb0a19cd>] ? get_parent_ip+0xd/0x50
  [<ffffffffbb17ac18>] handle_mm_fault+0x158/0xcb0
  [<ffffffffbb72594d>] ? retint_restore_args+0xe/0xe
  [<ffffffffbb728bb6>] __do_page_fault+0x1a6/0x620
  [<ffffffffbb11011e>] ? __acct_update_integrals+0x8e/0x120
  [<ffffffffbb0a19cd>] ? get_parent_ip+0xd/0x50
  [<ffffffffbb72949b>] ? preempt_count_sub+0x6b/0xf0
  [<ffffffffbb72904e>] do_page_fault+0x1e/0x70
Code: 75 1d 55 be 6c 00 00 00 48 c7 c7 8a 2f a2 bb 48 89 e5 e8 6c 49 95 ff 5d c6 05 74 16 65 00 01 c3 55 31 f6 48 89 e5 e8 28 bd a3 ff <0f> 0b 0f 1f 44 00 00 55 48 89 e5 41 57 45 31 ff 41 56 49 89 fe

RIP [<ffffffffbb718d98>]

Quoted 7 lines

That BUG is..

413 static inline int PageTransHuge(struct page *page) 414 {
415 VM_BUG_ON_PAGE(PageTail(page), page);
416 return PageHead(page);
417 }

Any idea which of the two PageTransHuge() calls in isolate_migratepages_range() that is? Offset far in the function suggest it's where the lru lock is already held, but I'm not sure as decodecode of your dump and objdump of my own compile look widely different.

If it's indeed the later PageTransHuge() call, it means that somebody else has cleared PageLRU and set PageTail (I don't think a page could have both at once) between the checks for PageLRU() and PageTransHuge() in isolate_migratepages_range(), while the latter was holding lru_lock. That's quite weird...

Vlastimil

Quoted 6 lines

--
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>

--
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>

author
#2 lore raw
Quoted 18 lines · Vlastimil Babka
Quoted 10 lines
RIP: 0010:[<ffffffffbb718d98>]  [<ffffffffbb718d98>] PageTransHuge.part.23+0xb/0xd
Call Trace:
  [<ffffffffbb1728a3>] isolate_migratepages_range+0x7a3/0x870
  [<ffffffffbb172d90>] compact_zone+0x370/0x560
  [<ffffffffbb173022>] compact_zone_order+0xa2/0x110
  [<ffffffffbb1733f1>] try_to_compact_pages+0x101/0x130
...
Code: 75 1d 55 be 6c 00 00 00 48 c7 c7 8a 2f a2 bb 48 89 e5 e8 6c 49 95 ff 5d c6 05 74 16 65 00 01 c3 55 31 f6 48 89 e5 e8 28 bd a3 ff <0f> 0b 0f 1f 44 00 00 55 48 89 e5 41 57 45 31 ff 41 56 49 89 fe

RIP [<ffffffffbb718d98>]

Quoted 7 lines

That BUG is..

413 static inline int PageTransHuge(struct page *page) 414 {
415 VM_BUG_ON_PAGE(PageTail(page), page);
416 return PageHead(page);
417 }

Quoted 4 lines

Any idea which of the two PageTransHuge() calls in isolate_migratepages_range() that is? Offset far in the function suggest it's where the lru lock is already held, but I'm not sure as decodecode of your dump and objdump of my own compile look widely different.

Yeah, the only thing the code: matches is the BUG() which is in another section. (see end of file at http://paste.fedoraproject.org/104155/40077293/raw/)

Maybe you can make more sense of that disassembly than I can..

Dave

--
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>

#3 lore raw
Quoted 20 lines · Dave Jones
Quoted 18 lines · Vlastimil Babka
Quoted 17 lines
RIP: 0010:[<ffffffffbb718d98>]  [<ffffffffbb718d98>] PageTransHuge.part.23+0xb/0xd
Call Trace:
  [<ffffffffbb1728a3>] isolate_migratepages_range+0x7a3/0x870
  [<ffffffffbb172d90>] compact_zone+0x370/0x560
  [<ffffffffbb173022>] compact_zone_order+0xa2/0x110
  [<ffffffffbb1733f1>] try_to_compact_pages+0x101/0x130
...
Code: 75 1d 55 be 6c 00 00 00 48 c7 c7 8a 2f a2 bb 48 89 e5 e8 6c 49 95 ff 5d c6 05 74 16 65 00 01 c3 55 31 f6 48 89 e5 e8 28 bd a3 ff <0f> 0b 0f 1f 44 00 00 55 48 89 e5 41 57 45 31 ff 41 56 49 89 fe

RIP [<ffffffffbb718d98>]

That BUG is..

413 static inline int PageTransHuge(struct page *page) 414 {
415 VM_BUG_ON_PAGE(PageTail(page), page);
416 return PageHead(page);
417 }

Quoted 6 lines
Quoted 4 lines

Any idea which of the two PageTransHuge() calls in isolate_migratepages_range() that is? Offset far in the function suggest it's where the lru lock is already held, but I'm not sure as decodecode of your dump and objdump of my own compile look widely different.

Yeah, the only thing the code: matches is the BUG() which is in another section.

Oh right, it's not a simple BUG_ON that would be inlined.

Quoted 3 lines

(see end of file at http://paste.fedoraproject.org/104155/40077293/raw/)

Maybe you can make more sense of that disassembly than I can..

Could you try adding -r to objdump, as now I have no idea where all those calls go :/

Quoted 9 lines

Dave

--
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>

--
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>

#4 lore raw
In reply to Dave Jones
Quoted 3 lines · Dave Jones

Not sure if Sasha has already reported this on -next (It's getting hard to keep track of all the VM bugs he's been finding), but I hit this overnight on .15-rc6. First time I've seen this one.

Unfortunately I had to disable transhuge/hugetlb in my testing .config since the open issues in -next get hit pretty often, and were unfixed for a while now.

Keeping them enabled just made it impossible to test anything else.

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>

#5 lore raw
Quoted 7 lines · Sasha Levin
Quoted 3 lines · Dave Jones

Not sure if Sasha has already reported this on -next (It's getting hard to keep track of all the VM bugs he's been finding), but I hit this overnight on .15-rc6. First time I've seen this one.

Unfortunately I had to disable transhuge/hugetlb in my testing .config since the open issues in -next get hit pretty often, and were unfixed for a while now.

Meh, I lost track. We should really consider something like bugzilla for this, IMHO.

Quoted 11 lines

Keeping them enabled just made it impossible to test anything else.

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>

--
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>

#6 lore raw
In reply to Sasha Levin
Quoted 8 lines · Sasha Levin
Quoted 3 lines · Dave Jones

Not sure if Sasha has already reported this on -next (It's getting hard to keep track of all the VM bugs he's been finding), but I hit this overnight on .15-rc6. First time I've seen this one.

Unfortunately I had to disable transhuge/hugetlb in my testing .config since the open issues in -next get hit pretty often, and were unfixed for a while now.

What THP-related is not fixed by now? collapse hung? what else?

Signature · 7 lines
 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>
#7 lore raw
Quoted 11 lines · Kirill A. Shutemov
Quoted 8 lines · Sasha Levin
Quoted 3 lines · Dave Jones

Not sure if Sasha has already reported this on -next (It's getting hard to keep track of all the VM bugs he's been finding), but I hit this overnight on .15-rc6. First time I've seen this one.

Unfortunately I had to disable transhuge/hugetlb in my testing .config since the open issues in -next get hit pretty often, and were unfixed for a while now.

What THP-related is not fixed by now? collapse hung? what else?

Besides the collapse hang, we have this: https://lkml.org/lkml/2013/3/29/103 .

I know it's not a "real" bug, but DEBUG_PAGEALLOC misbehaving, but it's still something that makes testing difficult.

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>