Skip to contentSkip to conversation

kernel BUG at mm/swap.c:134! - page dumped because: VM_BUG_ON_PAGE(page_mapcount(page) != 0)

DISCUSSION Linus Torvalds 5 participants 16 messages Apr 18, 2015 – Apr 27, 2015 1 message not in the archive Memory management

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Linus Torvalds

author
#1 lore raw
Quoted 10 lines · Borislav Petkov

so I'm running some intermediate state of linus/master + tip/master from Thursday and probably I shouldn't be even taking such splat seriously and wait until 4.1-rc1 has been done but let me report it just in case so that it is out there, in case someone else sees it too.

I don't have a reproducer yet except the fact that it happened twice already, the second time while watching the new Star Wars teaser on youtube (current->comm is "AudioThread" probably from chrome, as shown in the splat below).

Hmm. The only recent commit in this area seems to be 822fc61367f0 ("mm: don't call __page_cache_release for hugetlb") although I don't see why it would cause anything like that. But it changes code that has been stable for many years, which makes me wonder how valid it is (__put_compound_page() has been unchanged since 2011, and now suddenly it grew that "!PageHuge()" test).

So quite frankly, I'd almost suggest changing that

        if (!PageHuge(page))
                __page_cache_release(page);

back to the old unconditional __page_cache_release(page), and maybe add a single

        WARN_ON_ONCE(PageHuge(page));

just to see if that condition actually happens. The new comment says it shouldn't happen and that the change shouldn't matter, but...

Of course, your recent BUG_ON may well be entirely unrelated to this change in mm/swap.c, but it *is* in kind of the same area, and the timing would match too...

Linus

---

[115258.861335] page:ffffea0010a15040 count:0 mapcount:1 mapping:
    (null) index:0x0
[115258.869511] flags: 0x8000000000008014(referenced|dirty|tail)
[115258.874159] page dumped because: VM_BUG_ON_PAGE(page_mapcount(page) != 0)
[115258.874179] kernel BUG at mm/swap.c:134!
[115258.874262] RIP: put_compound_page+0x3b9/0x480

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

#2 lore raw
Quoted 11 lines · Linus Torvalds
Quoted 10 lines · Borislav Petkov

so I'm running some intermediate state of linus/master + tip/master from Thursday and probably I shouldn't be even taking such splat seriously and wait until 4.1-rc1 has been done but let me report it just in case so that it is out there, in case someone else sees it too.

I don't have a reproducer yet except the fact that it happened twice already, the second time while watching the new Star Wars teaser on youtube (current->comm is "AudioThread" probably from chrome, as shown in the splat below).

I would guess it's related to sound: the most common source of PTE-mapeed compund pages into userspace.

Quoted 14 lines

Hmm. The only recent commit in this area seems to be 822fc61367f0 ("mm: don't call __page_cache_release for hugetlb") although I don't see why it would cause anything like that. But it changes code that has been stable for many years, which makes me wonder how valid it is (__put_compound_page() has been unchanged since 2011, and now suddenly it grew that "!PageHuge()" test).

So quite frankly, I'd almost suggest changing that

        if (!PageHuge(page))
                __page_cache_release(page);

back to the old unconditional __page_cache_release(page), and maybe add a single

Quoted 8 lines
        WARN_ON_ONCE(PageHuge(page));

just to see if that condition actually happens. The new comment says it shouldn't happen and that the change shouldn't matter, but...

Of course, your recent BUG_ON may well be entirely unrelated to this change in mm/swap.c, but it *is* in kind of the same area, and the timing would match too...

Andrea has already seen the bug and pointed to 8d63d99a5dfb as possible cause. I don't see why the commit could broke anything, but it worth trying to revert and test.

Borislav, could you try?

Quoted 13 lines

---

[115258.861335] page:ffffea0010a15040 count:0 mapcount:1 mapping:
    (null) index:0x0
[115258.869511] flags: 0x8000000000008014(referenced|dirty|tail)
[115258.874159] page dumped because: VM_BUG_ON_PAGE(page_mapcount(page) != 0)
[115258.874179] kernel BUG at mm/swap.c:134!
[115258.874262] RIP: put_compound_page+0x3b9/0x480

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

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>
author
#3 lore raw
Quoted 4 lines · Kirill A. Shutemov

Andrea has already seen the bug and pointed to 8d63d99a5dfb as possible cause. I don't see why the commit could broke anything, but it worth trying to revert and test.

Ahh, yes, that does look like a more likely culprit.

Linus

--
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
Quoted 8 lines · Linus Torvalds
Quoted 4 lines · Kirill A. Shutemov

Andrea has already seen the bug and pointed to 8d63d99a5dfb as possible cause. I don't see why the commit could broke anything, but it worth trying to revert and test.

Ahh, yes, that does look like a more likely culprit.

Reverted and building... will report in the next days.

Thanks guys.

Signature · 11 lines
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

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

Forgot to CC lkml for archiving purposes, here's the whole thread in one:

---
Hi guys,

so I'm running some intermediate state of linus/master + tip/master from Thursday and probably I shouldn't be even taking such splat seriously and wait until 4.1-rc1 has been done but let me report it just in case so that it is out there, in case someone else sees it too.

I don't have a reproducer yet except the fact that it happened twice already, the second time while watching the new Star Wars teaser on youtube (current->comm is "AudioThread" probably from chrome, as shown in the splat below).

And srsly, to VM_BUG_ON_PAGE() while I'm watching the new Star Wars teaser - you must be kidding me people!

Anyway, just FYI, someone might have an idea...

So here's the state of what I was running:

---
commit 3963e69e59fa4e36ac164e8cd520811135d868d3
Merge: 34c9a0ffc75a 11664e41b11e
Author: Borislav Petkov <[email protected]>
Date: Thu Apr 16 13:39:44 2015 +0200

Merge remote-tracking branch 'tip/master' into rc0+

commit 11664e41b11ed447f598424dd83ecf65400be5a1 (refs/remotes/tip/master)
Merge: 61a7fd4deb61 2df8406a439b
Author: Ingo Molnar <[email protected]>
Date: Thu Apr 16 09:20:52 2015 +0200

Merge branch 'sched/urgent'

commit eea3a00264cf243a28e4331566ce67b86059339d
Merge: e7c82412433a e693d73c20ff
Author: Linus Torvalds <[email protected]>
Date: Wed Apr 15 16:39:15 2015 -0700

Merge branch 'akpm' (patches from Andrew)

Merge second patchbomb from Andrew Morton:

---

and here's the splat:

---

[115258.861335] page:ffffea0010a15040 count:0 mapcount:1 mapping:          (null) index:0x0
[115258.869511] flags: 0x8000000000008014(referenced|dirty|tail)
[115258.874159] page dumped because: VM_BUG_ON_PAGE(page_mapcount(page) != 0)
[115258.874177] ------------[ cut here ]------------
[115258.874179] kernel BUG at mm/swap.c:134!
[115258.874182] invalid opcode: 0000 [#1] 
[115258.874183] PREEMPT 
[115258.874184] SMP 
[115258.874187] Modules linked in:
[115258.874189]  nls_iso8859_15
[115258.874190]  nls_cp437
[115258.874192]  ipt_MASQUERADE
[115258.874193]  nf_nat_masquerade_ipv4
[115258.874194]  iptable_mangle
[115258.874195]  iptable_nat
[115258.874196]  nf_conntrack_ipv4
[115258.874198]  nf_defrag_ipv4
[115258.874199]  nf_nat_ipv4
[115258.874200]  nf_nat
[115258.874201]  nf_conntrack
[115258.874202]  iptable_filter
[115258.874204]  ip_tables
[115258.874205]  x_tables
[115258.874206]  tun
[115258.874207]  sha256_ssse3
[115258.874209]  sha256_generic
[115258.874211]  binfmt_misc
[115258.874212]  ipv6
[115258.874213]  vfat
[115258.874214]  fat
[115258.874215]  fuse
[115258.874216]  dm_crypt
[115258.874217]  dm_mod
[115258.874219]  kvm_amd
[115258.874243]  kvm crc32_pclmul aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd amd64_edac_mod edac_core fam15h_power k10temp amdkfd amd_iommu_v2 radeon drm_kms_helper ttm cfbfillrect cfbimgblt cfbcopyarea acpi_cpufreq
[115258.874248] CPU: 0 PID: 2904 Comm: AudioThread Not tainted 4.0.0+ #1
[115258.874250] Hardware name: To be filled by O.E.M. To be filled by O.E.M./M5A97 EVO R2.0, BIOS 1503 01/16/2013
[115258.874252] task: ffff8803e8278000 ti: ffff8803f8a04000 task.ti: ffff8803f8a04000
[115258.874262] RIP: 0010:[<ffffffff8113fcb9>]  [<ffffffff8113fcb9>] put_compound_page+0x3b9/0x480
[115258.874264] RSP: 0018:ffff8803f8a07b98  EFLAGS: 00010246
[115258.874266] RAX: 000000000000003d RBX: ffffea0010a15040 RCX: 0000000000000000
[115258.874268] RDX: ffffffff8109f016 RSI: ffffffff810bb33f RDI: ffffffff810bae60
[115258.874270] RBP: ffff8803f8a07bb8 R08: 0000000000000001 R09: 0000000000000001
[115258.874271] R10: 0000000000000001 R11: 0000000000000001 R12: ffffea0010a15000
[115258.874273] R13: ffff8803f8a07e28 R14: ffffea0010a15040 R15: 0000000000000000
[115258.874276] FS:  00007f206f2af700(0000) GS:ffff88042c600000(0000) knlGS:0000000000000000
[115258.874278] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[115258.874280] CR2: 00007f2095443310 CR3: 000000041e866000 CR4: 00000000000406f0
[115258.874281] Stack:
[115258.874287]  ffff8803f8a07e60 ffffea0010a151c0 ffff8803f8a07e28 ffffea0010a15040
[115258.874292]  ffff8803f8a07c28 ffffffff8113ffd0 0000000100000000 00000000ffffffff
[115258.874296]  ffff8803f8a07de8 ffff8803f8a07e60 ffff8803f8a07be8 ffff8803f8a07be8
[115258.874298] Call Trace:
[115258.874304]  [<ffffffff8113ffd0>] release_pages+0x250/0x270
[115258.874311]  [<ffffffff811736c5>] free_pages_and_swap_cache+0x95/0xb0
[115258.874317]  [<ffffffff8115ddc0>] tlb_flush_mmu_free+0x40/0x60
[115258.874323]  [<ffffffff8115fcac>] unmap_single_vma+0x69c/0x730
[115258.874331]  [<ffffffff81160594>] unmap_vmas+0x54/0xb0
[115258.874335]  [<ffffffff81165a38>] unmap_region+0xa8/0x110
[115258.874342]  [<ffffffff811679ea>] do_munmap+0x1ea/0x3f0
[115258.874346]  [<ffffffff81167c33>] ? vm_munmap+0x43/0x80
[115258.874350]  [<ffffffff81167c41>] vm_munmap+0x51/0x80
[115258.874354]  [<ffffffff81168bee>] SyS_munmap+0xe/0x20
[115258.874359]  [<ffffffff816918db>] system_call_fastpath+0x16/0x73
[115258.874424] Code: 81 48 89 df e8 29 c9 01 00 0f 0b 48 c7 c6 00 81 8a 81 4c 89 e7 e8 18 c9 01 00 0f 0b 48 c7 c6 d8 96 8b 81 48 89 df e8 07 c9 01 00 <0f> 0b 48 c7 c6 30 97 8b 81 48 89 df e8 f6 c8 01 00 0f 0b 48 c7 
[115258.874428] RIP  [<ffffffff8113fcb9>] put_compound_page+0x3b9/0x480
[115258.874429]  RSP <ffff8803f8a07b98>
[115258.898487] ---[ end trace 6ec080e8a6ee9fb1 ]---

Thanks!

Quoted 10 lines · Borislav Petkov

so I'm running some intermediate state of linus/master + tip/master from Thursday and probably I shouldn't be even taking such splat seriously and wait until 4.1-rc1 has been done but let me report it just in case so that it is out there, in case someone else sees it too.

I don't have a reproducer yet except the fact that it happened twice already, the second time while watching the new Star Wars teaser on youtube (current->comm is "AudioThread" probably from chrome, as shown in the splat below).

Hmm. The only recent commit in this area seems to be 822fc61367f0 ("mm: don't call __page_cache_release for hugetlb") although I don't see why it would cause anything like that. But it changes code that has been stable for many years, which makes me wonder how valid it is (__put_compound_page() has been unchanged since 2011, and now suddenly it grew that "!PageHuge()" test).

So quite frankly, I'd almost suggest changing that

        if (!PageHuge(page))
                __page_cache_release(page);

back to the old unconditional __page_cache_release(page), and maybe add a single

        WARN_ON_ONCE(PageHuge(page));

just to see if that condition actually happens. The new comment says it shouldn't happen and that the change shouldn't matter, but...

Of course, your recent BUG_ON may well be entirely unrelated to this change in mm/swap.c, but it *is* in kind of the same area, and the timing would match too...

Linus

---

[115258.861335] page:ffffea0010a15040 count:0 mapcount:1 mapping:
    (null) index:0x0
[115258.869511] flags: 0x8000000000008014(referenced|dirty|tail)
[115258.874159] page dumped because: VM_BUG_ON_PAGE(page_mapcount(page) != 0)
[115258.874179] kernel BUG at mm/swap.c:134!
[115258.874262] RIP: put_compound_page+0x3b9/0x480

---

Quoted 11 lines · Linus Torvalds
Quoted 10 lines · Borislav Petkov

so I'm running some intermediate state of linus/master + tip/master from Thursday and probably I shouldn't be even taking such splat seriously and wait until 4.1-rc1 has been done but let me report it just in case so that it is out there, in case someone else sees it too.

I don't have a reproducer yet except the fact that it happened twice already, the second time while watching the new Star Wars teaser on youtube (current->comm is "AudioThread" probably from chrome, as shown in the splat below).

I would guess it's related to sound: the most common source of PTE-mapeed compund pages into userspace.

Quoted 14 lines

Hmm. The only recent commit in this area seems to be 822fc61367f0 ("mm: don't call __page_cache_release for hugetlb") although I don't see why it would cause anything like that. But it changes code that has been stable for many years, which makes me wonder how valid it is (__put_compound_page() has been unchanged since 2011, and now suddenly it grew that "!PageHuge()" test).

So quite frankly, I'd almost suggest changing that

        if (!PageHuge(page))
                __page_cache_release(page);

back to the old unconditional __page_cache_release(page), and maybe add a single

Quoted 8 lines
        WARN_ON_ONCE(PageHuge(page));

just to see if that condition actually happens. The new comment says it shouldn't happen and that the change shouldn't matter, but...

Of course, your recent BUG_ON may well be entirely unrelated to this change in mm/swap.c, but it *is* in kind of the same area, and the timing would match too...

Andrea has already seen the bug and pointed to 8d63d99a5dfb as possible cause. I don't see why the commit could broke anything, but it worth trying to revert and test.

Borislav, could you try?

Quoted 13 lines

---

[115258.861335] page:ffffea0010a15040 count:0 mapcount:1 mapping:
    (null) index:0x0
[115258.869511] flags: 0x8000000000008014(referenced|dirty|tail)
[115258.874159] page dumped because: VM_BUG_ON_PAGE(page_mapcount(page) != 0)
[115258.874179] kernel BUG at mm/swap.c:134!
[115258.874262] RIP: put_compound_page+0x3b9/0x480

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

Signature · 4 lines
 Kirill A. Shutemov

---
On Sat, Apr 18, 2015 at 5:56 PM, Kirill A. Shutemov
Quoted 4 lines · <[email protected]> wrote:

Andrea has already seen the bug and pointed to 8d63d99a5dfb as possible cause. I don't see why the commit could broke anything, but it worth trying to revert and test.

Ahh, yes, that does look like a more likely culprit.

Linus

---

Quoted 8 lines · Linus Torvalds
Quoted 4 lines · Kirill A. Shutemov

Andrea has already seen the bug and pointed to 8d63d99a5dfb as possible cause. I don't see why the commit could broke anything, but it worth trying to revert and test.

Ahh, yes, that does look like a more likely culprit.

Reverted and building... will report in the next days.

Thanks guys.

Signature · 11 lines
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

--
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 Borislav Petkov
Quoted 11 lines · Borislav Petkov
Quoted 8 lines · Linus Torvalds
Quoted 4 lines · Kirill A. Shutemov

Andrea has already seen the bug and pointed to 8d63d99a5dfb as possible cause. I don't see why the commit could broke anything, but it worth trying to revert and test.

Ahh, yes, that does look like a more likely culprit.

Reverted and building... will report in the next days.

FWIW, box is solid with the revert and has an uptime of ~4 days so far without hickups.

Signature · 11 lines
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

--
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 9 lines · Borislav Petkov
Quoted 8 lines · Borislav Petkov
Quoted 7 lines · Linus Torvalds
Quoted 4 lines · Kirill A. Shutemov

Andrea has already seen the bug and pointed to 8d63d99a5dfb as possible cause. I don't see why the commit could broke anything, but it worth trying to revert and test.

Quoted 6 lines
Quoted 3 lines
Quoted 1 line

Ahh, yes, that does look like a more likely culprit.

Reverted and building... will report in the next days.

FWIW, box is solid with the revert and has an uptime of ~4 days so far without hickups.

Could you try patch below instead? This can give a clue what's going on.

mm/swap.c +5 -1
index a7251a8ed532..0dff7004aa25 100644
@@ -131,7 +131,11 @@ void put_unrefcounted_compound_page(struct page *page_head, struct page *page)
 		 * here, see the comment above this function.
 		 */
 		VM_BUG_ON_PAGE(!PageHead(page_head), page_head);
-		VM_BUG_ON_PAGE(page_mapcount(page) != 0, page);
+		if (page_mapcount(page) != 0) {
+			dump_page(page_head, NULL);
+			dump_page(page, NULL);
+			BUG();
+		}
 		if (put_page_testzero(page_head)) {
 			/*
 			 * If this is the tail of a slab THP page,
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>
#8 lore raw
Quoted 1 line · Kirill A. Shutemov

Could you try patch below instead? This can give a clue what's going on.

Well, this happens on my workstation and I need it for work. I'll try to find another box to reproduce it on first. You could try to reproduce it too - it happened here while playing videos on youtube in chromium. But it is not easy to trigger, no particular use pattern. So I don't have a sure-fire way of reproducing it.

I can send you my .config if you need it.

HTH

Signature · 11 lines
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

--
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>
#9 lore raw
Quoted 8 lines · Borislav Petkov
Quoted 1 line · Kirill A. Shutemov

Could you try patch below instead? This can give a clue what's going on.

Well, this happens on my workstation and I need it for work. I'll try to find another box to reproduce it on first. You could try to reproduce it too - it happened here while playing videos on youtube in chromium. But it is not easy to trigger, no particular use pattern. So I don't have a sure-fire way of reproducing it.

I'm running kernel with this patch on my laptop for few day without a crash. :-/

Quoted 1 line

I can send you my .config if you need it.

Yes, please.

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>
#10 lore raw
Quoted 2 lines · Kirill A. Shutemov

I'm running kernel with this patch on my laptop for few day without a crash. :-/

If I'm to venture a wild guess, you probably need a bigger box for the proper preconditions. I have 16G here. But just a wild guess anyway.

Quoted 1 line

Yes, please.

Attached.

Signature · 5 lines
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
author
#11 lore raw
In reply to Kirill A. Shutemov
Quoted 2 lines · Kirill A. Shutemov

Could you try patch below instead? This can give a clue what's going on.

Just FYI, I've done the revert in my tree.

Trying to figure out what is going on despite that is obviously a good idea, but I'm hoping that my merge window is winding down, so I am trying to make sure it's all "good to go"..

Linus

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

#12 lore raw
Quoted 10 lines · Linus Torvalds
Quoted 2 lines · Kirill A. Shutemov

Could you try patch below instead? This can give a clue what's going on.

Just FYI, I've done the revert in my tree.

Trying to figure out what is going on despite that is obviously a good idea, but I'm hoping that my merge window is winding down, so I am trying to make sure it's all "good to go"..

Sounds safer to defer it, agreed.

Unfortunately I also can only reproduce it only on a workstation where it wasn't very handy to debug it as it'd disrupt my workflow and it isn't equipped with reliable logging either (and the KMS mode didn't switch to console to show me the oops either). It just got it logged once in syslog before freezing.

The problem has to be that there's some get_page/put_page activity before and after a PageAnon transition and it looks like a tail page got mapped by hand in userland by some driver using 4k ptes which isn't normal but apparently safe before the patch was applied. Before the patch, the tail page accounting would be symmetric regardless of the PageAnon transition.

page:ffffea0010226040 count:0 mapcount:1 mapping: (null) index:0x0
flags: 0x8000000000008010(dirty|tail)

page dumped because: VM_BUG_ON_PAGE(page_mapcount(page) != 0)
------------[ cut here ]------------
kernel BUG at mm/swap.c:134!
invalid opcode: 0000 [#1] SMP
Modules linked in: tun usbhid x86_pkg_temp_thermal kvm_intel kvm snd_hda_codec_realtek snd_hd
d_hda_intel xhci_pci ehci_hcd snd_hda_controller xhci_hcd snd_hda_codec snd_hda_core snd_pcm
d psmouse cdrom pcspkr usb_common [last unloaded: microcode]
CPU: 1 PID: 4175 Comm: knotify4 Not tainted 4.0.0+ #18
Hardware name:                  /DH61BE, BIOS BEH6110H.86A.0120.2013.1112.1412 11/12/2013
task: ffff88040ca231e0 ti: ffff8800bd088000 task.ti: ffff8800bd088000
RIP: 0010:[<ffffffff81148baa>]  [<ffffffff81148baa>] put_compound_page+0x31a/0x320
RSP: 0018:ffff8800bd08bc48  EFLAGS: 00010246
RAX: 000000000000003d RBX: ffffea0010226040 RCX: 0000000000000006
RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff88041f24d310
RBP: ffffea0010226000 R08: 0000000000000400 R09: ffffffff81ccaf54
R10: 00000000000002f3 R11: 00000000000002f2 R12: ffff8800bd08be20
R13: ffff8800bd08be70 R14: 00007ff3d9772000 R15: 0000000000000000
FS:  00007ff3d2693700(0000) GS:ffff88041f240000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f877f137000 CR3: 00000003dd5b4000 CR4: 00000000000407e0
Stack:
ffff8800bd08bd0a ffffea0010226040 ffff8800bd08be38 ffffffff81148dd2
0000000000000002 00000000bd08be20 ffff8800bd08bc78 ffff8800bd08bc78
ffffea00102261c0 ffff8800bd08be20 ffff8800bd08bdf8 ffff8800bd08be20
Call Trace:
[<ffffffff81148dd2>] ? release_pages+0x222/0x260
[<ffffffff81160d80>] ? tlb_flush_mmu_free+0x30/0x50
[<ffffffff81162a00>] ? unmap_single_vma+0x580/0x810
[<ffffffff811634c1>] ? unmap_vmas+0x41/0x90
[<ffffffff81168125>] ? unmap_region+0x85/0xf0
[<ffffffff8116a17d>] ? do_munmap+0x21d/0x390
[<ffffffff8116a32a>] ? vm_munmap+0x3a/0x60
[<ffffffff8116b2ac>] ? SyS_munmap+0x1c/0x30
[<ffffffff8176d897>] ? system_call_fastpath+0x12/0x6a
Code: 81 48 89 ef e8 08 6d 01 00 0f 0b 48 c7 c6 f0 e9 9c 81 48 89 ef e8 f7 6c 01 00 0f 0b 48
e8 e6 6c 01 00 <0f> 0b 0f 1f 40 00 41 57 41 56 41 55 41 54 55 53 48 83 ec 28 85
RIP  [<ffffffff81148baa>] put_compound_page+0x31a/0x320
RSP <ffff8800bd08bc48>
---[ end trace 81df9d42bd21b1f5 ]---

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

#13 lore raw
Quoted 20 lines · Andrea Arcangeli
Quoted 10 lines · Linus Torvalds
Quoted 2 lines · Kirill A. Shutemov

Could you try patch below instead? This can give a clue what's going on.

Just FYI, I've done the revert in my tree.

Trying to figure out what is going on despite that is obviously a good idea, but I'm hoping that my merge window is winding down, so I am trying to make sure it's all "good to go"..

Sounds safer to defer it, agreed.

Unfortunately I also can only reproduce it only on a workstation where it wasn't very handy to debug it as it'd disrupt my workflow and it isn't equipped with reliable logging either (and the KMS mode didn't switch to console to show me the oops either). It just got it logged once in syslog before freezing.

Quoted 4 lines

The problem has to be that there's some get_page/put_page activity before and after a PageAnon transition and it looks like a tail page got mapped by hand in userland by some driver using 4k ptes which isn't normal

Compound pages mapped with PTEs predates THP. See f3d48f0373c1.

Quoted 9 lines

but apparently safe before the patch was applied. Before the patch, the tail page accounting would be symmetric regardless of the PageAnon transition.

page:ffffea0010226040 count:0 mapcount:1 mapping: (null) index:0x0
flags: 0x8000000000008010(dirty|tail)

page dumped because: VM_BUG_ON_PAGE(page_mapcount(page) != 0)
------------[ cut here ]------------
kernel BUG at mm/swap.c:134!

I looked into code a bit more. And the VM_BUG_ON_PAGE() is bogus. See explanation in commit message below.

Tail page refcounting is mess. Please consider reviewing my patchset which drops it [1]. ;)

Linus, how should we proceed with reverted patch? Should I re-submit it to Andrew? Or you'll re-revert it?

[1] lkml.kernel.org/g/1429823043-157133-1-git-send-email-kirill.shutemov@linux.intel.com

Reviewed-by
#14 lore raw

Hello,

Quoted 21 lines · Kirill A. Shutemov
Quoted 20 lines · Andrea Arcangeli
Quoted 10 lines · Linus Torvalds
Quoted 2 lines · Kirill A. Shutemov

Could you try patch below instead? This can give a clue what's going on.

Just FYI, I've done the revert in my tree.

Trying to figure out what is going on despite that is obviously a good idea, but I'm hoping that my merge window is winding down, so I am trying to make sure it's all "good to go"..

Sounds safer to defer it, agreed.

Unfortunately I also can only reproduce it only on a workstation where it wasn't very handy to debug it as it'd disrupt my workflow and it isn't equipped with reliable logging either (and the KMS mode didn't switch to console to show me the oops either). It just got it logged once in syslog before freezing.

Quoted 6 lines
Quoted 4 lines

The problem has to be that there's some get_page/put_page activity before and after a PageAnon transition and it looks like a tail page got mapped by hand in userland by some driver using 4k ptes which isn't normal

Compound pages mapped with PTEs predates THP. See f3d48f0373c1.

Yes, I intended "normal" as a feeling about it considering it's your new patchset that tries to introduce that behavior for regular anon pages, I didn't imply it was not ok for driver-owned pages, sorry for the confusion.

Quoted 8 lines

I looked into code a bit more. And the VM_BUG_ON_PAGE() is bogus. See explanation in commit message below.

Tail page refcounting is mess. Please consider reviewing my patchset which drops it [1]. ;)

Linus, how should we proceed with reverted patch? Should I re-submit it to Andrew? Or you'll re-revert it?

You could resubmit the old patch together with this patch, so they go together.

In retrospect it may have been cleaner to pick another field than mapcount for the tail page refcounting, then the VM_BUG_ON could have been retained.

mapcount was picked as candidate of tail page refcounting, because it already implemented a "count" too so it was simpler to use than another random 32bit word and didn't require further unions into the page struct.

page_count cannot be used for refcounting tail pages of THP or speculative pagecache lookups race against split_huge_page_refcount. For non-THP it doesn't matter, even page_count could have been used or even better no tail refcounting at all like with your patch.

With your patch you're basically disabling the tail page refcounting for those usages so it probably doesn't matter anymore to move away from mapcount and removing the VM_BUG_ON doesn't concern me by now (it never actually triggered before).

Even for those usages doubling up the refcounting in mapcount, the refcounting of 4.0 was safe. The false positive VM_BUG_ON could only happen only after the change.

Quoted 20 lines

[1] lkml.kernel.org/g/1429823043-157133-1-git-send-email-kirill.shutemov@linux.intel.com

From 854cdc961b7f83f04a83144ab4f7459ae46b0f3d Mon Sep 17 00:00:00 2001
From: "Kirill A. Shutemov" <[email protected]>
Date: Fri, 24 Apr 2015 23:49:04 +0300
Subject: [PATCH] mm: drop bogus VM_BUG_ON_PAGE assert in put_page() codepath

My patch 8d63d99a5dfb which was merged during 4.1 merge window caused regression:

page:ffffea0010a15040 count:0 mapcount:1 mapping: (null) index:0x0
flags: 0x8000000000008014(referenced|dirty|tail)

  page dumped because: VM_BUG_ON_PAGE(page_mapcount(page) != 0)
  ------------[ cut here ]------------
  kernel BUG at mm/swap.c:134!

The problem can be reproduced by playing *two* audio files at the same time and then stopping one of players. I used two mplayers to trigger this.

Quoted 6 lines

The VM_BUG_ON_PAGE() which triggers the bug is bogus:

Sound subsystem uses compound pages for its buffers, but unlike most __GFP_COMP users sound maps compound pages to userspace with PTEs.

In our case with two players map the buffer twice and therefore elevates

I didn't think at the case of mapping the same compound page twice in userland, this clearly explains the crash. I thought it had to be the PageAnon flipping somehow but I couldn't explain where... and in fact it was something else.

Quoted 14 lines
Signed-off-by Kirill A. Shutemov <[email protected]>
Reported-by Andrea Arcangeli <[email protected]>
Reported-by Borislav Petkov <[email protected]>
Cc Hugh Dickins <[email protected]>
Cc Andrew Morton <[email protected]>
---
 mm/swap.c | 1 -
 1 file changed, 1 deletion(-)
mm/swap.c +0 -0
index a7251a8ed532..a3a0a2f1f7c3 100644

mm/swap.c void put_unrefcounted_compound_page(struct page *page_head, struct page *page) · line 136

Quoted 7 lines
mm/swap.c +0 -1
@@ -131,7 +131,6 @@ void put_unrefcounted_compound_page(struct page *page_head, struct page *page)
 		 * here, see the comment above this function.
 		 */
 		VM_BUG_ON_PAGE(!PageHead(page_head), page_head);
-		VM_BUG_ON_PAGE(page_mapcount(page) != 0, page);
 		if (put_page_testzero(page_head)) {
 			/*
 			 * If this is the tail of a slab THP page,
Reviewed-by Andrea Arcangeli <[email protected]>

If you resend a consolidated commit with the two changes in the same commit, feel free to retain the Reviewed-by for both.

Optionally you could turn it into a VM_BUG_ON_PAGE(page_mapcount(page) < 0, page) but it's up to you.

Thanks,
Andrea

--
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
#15 lore raw
In reply to Linus Torvalds
Quoted 8 lines · Linus Torvalds
Quoted 4 lines · Kirill A. Shutemov

Andrea has already seen the bug and pointed to 8d63d99a5dfb as possible cause. I don't see why the commit could broke anything, but it worth trying to revert and test.

Ahh, yes, that does look like a more likely culprit.

That said, I do think we should likely also do that

        WARN_ON_ONCE(PageHuge(page));

in __put_compound_page() rather than just silently saying "no refcount changes for this magical case that shouldn't even happen". If it shouldn't happen, then we should warn about it, not try to ":handle" some case that shouldn't happen and shouldn't matter.

Let's not play games in this area. This code has been stable for many years, why are we suddenly doing random things here? There's something to be said for "if it ain't broke..", and there's *definitely* a lot to be said for "let's not complicate this even more".

Linus

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

#16 lore raw
Quoted 11 lines · Linus Torvalds
Quoted 8 lines · Linus Torvalds
Quoted 4 lines · Kirill A. Shutemov

Andrea has already seen the bug and pointed to 8d63d99a5dfb as possible cause. I don't see why the commit could broke anything, but it worth trying to revert and test.

Ahh, yes, that does look like a more likely culprit.

Quoted 8 lines

That said, I do think we should likely also do that

        WARN_ON_ONCE(PageHuge(page));

in __put_compound_page() rather than just silently saying "no refcount changes for this magical case that shouldn't even happen". If it shouldn't happen, then we should warn about it, not try to ":handle" some case that shouldn't happen and shouldn't matter.

__put_compound_page() can be called for PageHuge, so I don't think that adding WARN_ON_ONCE(PageHuge) is good (, which makes every hugetlb user see the warning once in every boot.)

What I thought when I suggested this code was that __page_cache_release() seems not to be intended for hugetlb, but I'm not sure. __put_compound_page() does work without this !PageHuge check which is only for potential change in __put_compound_page().
So if everyone thinks that __put_compound_page() is stable and will never change in the future, this !PageHuge check is totally unnecessary.

Quoted 4 lines

Let's not play games in this area. This code has been stable for many years, why are we suddenly doing random things here? There's something to be said for "if it ain't broke..", and there's *definitely* a lot to be said for "let's not complicate this even more".

OK, so could you please try simply reverting 822fc61367f0 ?

Thanks,
Naoya Horiguchi

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