* Re: mm: BUG in pgtable_pmd_page_dtor
@ 2016-11-25 8:42 ` Vlastimil Babka
0 siblings, 0 replies; 24+ messages in thread
From: Vlastimil Babka @ 2016-11-25 8:42 UTC (permalink / raw)
To: Dmitry Vyukov, Andrew Morton
Cc: Kirill A. Shutemov, Michal Hocko, Ingo Molnar, Joonsoo Kim,
linux-mm@kvack.org, LKML, Andrey Ryabinin, syzkaller
On 11/24/2016 03:23 PM, Dmitry Vyukov wrote:
> On Thu, Nov 24, 2016 at 2:49 PM, Vlastimil Babka <vbabka@suse.cz> wrote:
>> On 11/18/2016 11:19 AM, Dmitry Vyukov wrote:
>>>
>>> Hello,
>>>
>>> I've got the following BUG while running syzkaller on
>>> a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6 (4.9-rc5). Unfortunately it's
>>> not reproducible.
>>>
>>> kernel BUG at ./include/linux/mm.h:1743!
>>> invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
>>
>>
>> Shouldn't there be also dump_page() output? Since you've hit this:
>> VM_BUG_ON_PAGE(page->pmd_huge_pte, page);
>
> Here it is:
>
> [ 250.326131] page:ffffea0000e196c0 count:1 mapcount:0 mapping:
> (null) index:0x0
> [ 250.343393] flags: 0x1fffc0000000000()
> [ 250.345328] page dumped because: VM_BUG_ON_PAGE(page->pmd_huge_pte)
> [ 250.346780] ------------[ cut here ]------------
> [ 250.347742] kernel BUG at ./include/linux/mm.h:1743!
Yeah, as expected, not very useful for this particular BUG_ON :/
>> Anyway the output wouldn't contain the value of pmd_huge_pte or stuff that's
>> in union with it. I'd suggest adding a local patch that prints this in the
>> error case, in case the fuzzer hits it again.
>>
>> Heck, it might even make sense to print raw contents of struct page in
>> dump_page() as a catch-all solution? Should I send a patch?
>
> Yes, please send.
> We are moving towards continuous build without local patches.
Something like this?
-------8<-------
>From 2ac2c9b83d7c4c8be076c24246865a2ed01f9032 Mon Sep 17 00:00:00 2001
From: Vlastimil Babka <vbabka@suse.cz>
Date: Fri, 25 Nov 2016 09:08:05 +0100
Subject: [PATCH] mm, debug: print raw struct page data in __dump_page()
The __dump_page() function is used when a page metadata inconsistency is
detected, either by standard runtime checks, or extra checks in CONFIG_DEBUG_VM
builds. It prints some of the relevant metadata, but not the whole struct page,
which is based on unions and interpretation is dependent on the context.
This means that sometimes e.g. a VM_BUG_ON_PAGE() checks certain field, which
is however not printed by __dump_page() and the resulting bug report may then
lack clues that could help in determining the root cause. This patch solves
the problem by simply printing the whole struct page word by word, so no part
is missing, but the interpretation of the data is left to developers. This is
similar to e.g. x86_64 raw stack dumps.
Example output:
page:ffffea00000475c0 count:1 mapcount:0 mapping: (null) index:0x0
flags: 0x100000000000400(reserved)
raw struct page data:
0100000000000400 0000000000000000 0000000000000000 00000001ffffffff
ffffea00000475e0 ffffea00000475e0 0000000000000000 0000000000000000
page dumped because: VM_BUG_ON_PAGE(1)
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
---
mm/debug.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/mm/debug.c b/mm/debug.c
index 9feb699c5d25..9f67ad74d036 100644
--- a/mm/debug.c
+++ b/mm/debug.c
@@ -48,6 +48,8 @@ void __dump_page(struct page *page, const char *reason)
* encode own info.
*/
int mapcount = PageSlab(page) ? 0 : page_mapcount(page);
+ int i;
+ const int words_per_line = (sizeof(unsigned long) == 8) ? 4 : 8;
pr_emerg("page:%p count:%d mapcount:%d mapping:%p index:%#lx",
page, page_ref_count(page), mapcount,
@@ -59,6 +61,21 @@ void __dump_page(struct page *page, const char *reason)
pr_emerg("flags: %#lx(%pGp)\n", page->flags, &page->flags);
+ pr_alert("raw struct page data:");
+ for (i = 0; i < sizeof(struct page) / sizeof(unsigned long); i++) {
+ unsigned long *word_ptr;
+
+ word_ptr = ((unsigned long *) page) + i;
+
+ if ((i % words_per_line) == 0) {
+ pr_cont("\n");
+ pr_alert(" %016lx", *word_ptr);
+ } else {
+ pr_cont(" %016lx", *word_ptr);
+ }
+ }
+ pr_cont("\n");
+
if (reason)
pr_alert("page dumped because: %s\n", reason);
--
2.10.2
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: mm: BUG in pgtable_pmd_page_dtor
2016-11-25 8:42 ` Vlastimil Babka
@ 2016-11-25 10:48 ` Kirill A. Shutemov
-1 siblings, 0 replies; 24+ messages in thread
From: Kirill A. Shutemov @ 2016-11-25 10:48 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Dmitry Vyukov, Andrew Morton, Kirill A. Shutemov, Michal Hocko,
Ingo Molnar, Joonsoo Kim, linux-mm@kvack.org, LKML,
Andrey Ryabinin, syzkaller
On Fri, Nov 25, 2016 at 09:42:07AM +0100, Vlastimil Babka wrote:
> On 11/24/2016 03:23 PM, Dmitry Vyukov wrote:
> > On Thu, Nov 24, 2016 at 2:49 PM, Vlastimil Babka <vbabka@suse.cz> wrote:
> >> On 11/18/2016 11:19 AM, Dmitry Vyukov wrote:
> >>>
> >>> Hello,
> >>>
> >>> I've got the following BUG while running syzkaller on
> >>> a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6 (4.9-rc5). Unfortunately it's
> >>> not reproducible.
> >>>
> >>> kernel BUG at ./include/linux/mm.h:1743!
> >>> invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
> >>
> >>
> >> Shouldn't there be also dump_page() output? Since you've hit this:
> >> VM_BUG_ON_PAGE(page->pmd_huge_pte, page);
> >
> > Here it is:
> >
> > [ 250.326131] page:ffffea0000e196c0 count:1 mapcount:0 mapping:
> > (null) index:0x0
> > [ 250.343393] flags: 0x1fffc0000000000()
> > [ 250.345328] page dumped because: VM_BUG_ON_PAGE(page->pmd_huge_pte)
> > [ 250.346780] ------------[ cut here ]------------
> > [ 250.347742] kernel BUG at ./include/linux/mm.h:1743!
>
> Yeah, as expected, not very useful for this particular BUG_ON :/
>
> >> Anyway the output wouldn't contain the value of pmd_huge_pte or stuff that's
> >> in union with it. I'd suggest adding a local patch that prints this in the
> >> error case, in case the fuzzer hits it again.
> >>
> >> Heck, it might even make sense to print raw contents of struct page in
> >> dump_page() as a catch-all solution? Should I send a patch?
> >
> > Yes, please send.
> > We are moving towards continuous build without local patches.
>
> Something like this?
> -------8<-------
> From 2ac2c9b83d7c4c8be076c24246865a2ed01f9032 Mon Sep 17 00:00:00 2001
> From: Vlastimil Babka <vbabka@suse.cz>
> Date: Fri, 25 Nov 2016 09:08:05 +0100
> Subject: [PATCH] mm, debug: print raw struct page data in __dump_page()
>
> The __dump_page() function is used when a page metadata inconsistency is
> detected, either by standard runtime checks, or extra checks in CONFIG_DEBUG_VM
> builds. It prints some of the relevant metadata, but not the whole struct page,
> which is based on unions and interpretation is dependent on the context.
>
> This means that sometimes e.g. a VM_BUG_ON_PAGE() checks certain field, which
> is however not printed by __dump_page() and the resulting bug report may then
> lack clues that could help in determining the root cause. This patch solves
> the problem by simply printing the whole struct page word by word, so no part
> is missing, but the interpretation of the data is left to developers. This is
> similar to e.g. x86_64 raw stack dumps.
>
> Example output:
>
> page:ffffea00000475c0 count:1 mapcount:0 mapping: (null) index:0x0
> flags: 0x100000000000400(reserved)
> raw struct page data:
> 0100000000000400 0000000000000000 0000000000000000 00000001ffffffff
> ffffea00000475e0 ffffea00000475e0 0000000000000000 0000000000000000
> page dumped because: VM_BUG_ON_PAGE(1)
>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> ---
> mm/debug.c | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/mm/debug.c b/mm/debug.c
> index 9feb699c5d25..9f67ad74d036 100644
> --- a/mm/debug.c
> +++ b/mm/debug.c
> @@ -48,6 +48,8 @@ void __dump_page(struct page *page, const char *reason)
> * encode own info.
> */
> int mapcount = PageSlab(page) ? 0 : page_mapcount(page);
> + int i;
> + const int words_per_line = (sizeof(unsigned long) == 8) ? 4 : 8;
>
> pr_emerg("page:%p count:%d mapcount:%d mapping:%p index:%#lx",
> page, page_ref_count(page), mapcount,
> @@ -59,6 +61,21 @@ void __dump_page(struct page *page, const char *reason)
>
> pr_emerg("flags: %#lx(%pGp)\n", page->flags, &page->flags);
>
> + pr_alert("raw struct page data:");
Do we really need this line? I would like to keep dump_page() output as
compact as possible.
> + for (i = 0; i < sizeof(struct page) / sizeof(unsigned long); i++) {
> + unsigned long *word_ptr;
> +
> + word_ptr = ((unsigned long *) page) + i;
> +
> + if ((i % words_per_line) == 0) {
> + pr_cont("\n");
> + pr_alert(" %016lx", *word_ptr);
> + } else {
> + pr_cont(" %016lx", *word_ptr);
16 is a waste on 32-bit system. And it will produce too long lines.
Maybe 'unsigned long long' a time?
> + }
> + }
> + pr_cont("\n");
> +
> if (reason)
> pr_alert("page dumped because: %s\n", reason);
>
> --
> 2.10.2
>
>
> --
> 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>
--
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] 24+ messages in thread* Re: mm: BUG in pgtable_pmd_page_dtor
@ 2016-11-25 10:48 ` Kirill A. Shutemov
0 siblings, 0 replies; 24+ messages in thread
From: Kirill A. Shutemov @ 2016-11-25 10:48 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Dmitry Vyukov, Andrew Morton, Kirill A. Shutemov, Michal Hocko,
Ingo Molnar, Joonsoo Kim, linux-mm@kvack.org, LKML,
Andrey Ryabinin, syzkaller
On Fri, Nov 25, 2016 at 09:42:07AM +0100, Vlastimil Babka wrote:
> On 11/24/2016 03:23 PM, Dmitry Vyukov wrote:
> > On Thu, Nov 24, 2016 at 2:49 PM, Vlastimil Babka <vbabka@suse.cz> wrote:
> >> On 11/18/2016 11:19 AM, Dmitry Vyukov wrote:
> >>>
> >>> Hello,
> >>>
> >>> I've got the following BUG while running syzkaller on
> >>> a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6 (4.9-rc5). Unfortunately it's
> >>> not reproducible.
> >>>
> >>> kernel BUG at ./include/linux/mm.h:1743!
> >>> invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
> >>
> >>
> >> Shouldn't there be also dump_page() output? Since you've hit this:
> >> VM_BUG_ON_PAGE(page->pmd_huge_pte, page);
> >
> > Here it is:
> >
> > [ 250.326131] page:ffffea0000e196c0 count:1 mapcount:0 mapping:
> > (null) index:0x0
> > [ 250.343393] flags: 0x1fffc0000000000()
> > [ 250.345328] page dumped because: VM_BUG_ON_PAGE(page->pmd_huge_pte)
> > [ 250.346780] ------------[ cut here ]------------
> > [ 250.347742] kernel BUG at ./include/linux/mm.h:1743!
>
> Yeah, as expected, not very useful for this particular BUG_ON :/
>
> >> Anyway the output wouldn't contain the value of pmd_huge_pte or stuff that's
> >> in union with it. I'd suggest adding a local patch that prints this in the
> >> error case, in case the fuzzer hits it again.
> >>
> >> Heck, it might even make sense to print raw contents of struct page in
> >> dump_page() as a catch-all solution? Should I send a patch?
> >
> > Yes, please send.
> > We are moving towards continuous build without local patches.
>
> Something like this?
> -------8<-------
> From 2ac2c9b83d7c4c8be076c24246865a2ed01f9032 Mon Sep 17 00:00:00 2001
> From: Vlastimil Babka <vbabka@suse.cz>
> Date: Fri, 25 Nov 2016 09:08:05 +0100
> Subject: [PATCH] mm, debug: print raw struct page data in __dump_page()
>
> The __dump_page() function is used when a page metadata inconsistency is
> detected, either by standard runtime checks, or extra checks in CONFIG_DEBUG_VM
> builds. It prints some of the relevant metadata, but not the whole struct page,
> which is based on unions and interpretation is dependent on the context.
>
> This means that sometimes e.g. a VM_BUG_ON_PAGE() checks certain field, which
> is however not printed by __dump_page() and the resulting bug report may then
> lack clues that could help in determining the root cause. This patch solves
> the problem by simply printing the whole struct page word by word, so no part
> is missing, but the interpretation of the data is left to developers. This is
> similar to e.g. x86_64 raw stack dumps.
>
> Example output:
>
> page:ffffea00000475c0 count:1 mapcount:0 mapping: (null) index:0x0
> flags: 0x100000000000400(reserved)
> raw struct page data:
> 0100000000000400 0000000000000000 0000000000000000 00000001ffffffff
> ffffea00000475e0 ffffea00000475e0 0000000000000000 0000000000000000
> page dumped because: VM_BUG_ON_PAGE(1)
>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> ---
> mm/debug.c | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/mm/debug.c b/mm/debug.c
> index 9feb699c5d25..9f67ad74d036 100644
> --- a/mm/debug.c
> +++ b/mm/debug.c
> @@ -48,6 +48,8 @@ void __dump_page(struct page *page, const char *reason)
> * encode own info.
> */
> int mapcount = PageSlab(page) ? 0 : page_mapcount(page);
> + int i;
> + const int words_per_line = (sizeof(unsigned long) == 8) ? 4 : 8;
>
> pr_emerg("page:%p count:%d mapcount:%d mapping:%p index:%#lx",
> page, page_ref_count(page), mapcount,
> @@ -59,6 +61,21 @@ void __dump_page(struct page *page, const char *reason)
>
> pr_emerg("flags: %#lx(%pGp)\n", page->flags, &page->flags);
>
> + pr_alert("raw struct page data:");
Do we really need this line? I would like to keep dump_page() output as
compact as possible.
> + for (i = 0; i < sizeof(struct page) / sizeof(unsigned long); i++) {
> + unsigned long *word_ptr;
> +
> + word_ptr = ((unsigned long *) page) + i;
> +
> + if ((i % words_per_line) == 0) {
> + pr_cont("\n");
> + pr_alert(" %016lx", *word_ptr);
> + } else {
> + pr_cont(" %016lx", *word_ptr);
16 is a waste on 32-bit system. And it will produce too long lines.
Maybe 'unsigned long long' a time?
> + }
> + }
> + pr_cont("\n");
> +
> if (reason)
> pr_alert("page dumped because: %s\n", reason);
>
> --
> 2.10.2
>
>
> --
> 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>
--
Kirill A. Shutemov
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: mm: BUG in pgtable_pmd_page_dtor
2016-11-25 8:42 ` Vlastimil Babka
@ 2016-11-25 11:41 ` Andrey Ryabinin
-1 siblings, 0 replies; 24+ messages in thread
From: Andrey Ryabinin @ 2016-11-25 11:41 UTC (permalink / raw)
To: Vlastimil Babka, Dmitry Vyukov, Andrew Morton
Cc: Kirill A. Shutemov, Michal Hocko, Ingo Molnar, Joonsoo Kim,
linux-mm@kvack.org, LKML, syzkaller
On 11/25/2016 11:42 AM, Vlastimil Babka wrote:
> pr_emerg("page:%p count:%d mapcount:%d mapping:%p index:%#lx",
> page, page_ref_count(page), mapcount,
> @@ -59,6 +61,21 @@ void __dump_page(struct page *page, const char *reason)
>
> pr_emerg("flags: %#lx(%pGp)\n", page->flags, &page->flags);
>
> + pr_alert("raw struct page data:");
> + for (i = 0; i < sizeof(struct page) / sizeof(unsigned long); i++) {
> + unsigned long *word_ptr;
> +
> + word_ptr = ((unsigned long *) page) + i;
> +
> + if ((i % words_per_line) == 0) {
> + pr_cont("\n");
> + pr_alert(" %016lx", *word_ptr);
> + } else {
> + pr_cont(" %016lx", *word_ptr);
> + }
> + }
> + pr_cont("\n");
> +
Single call to print_hex_dump() could replace this loop.
> if (reason)
> pr_alert("page dumped because: %s\n", reason);
>
>
--
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] 24+ messages in thread* Re: mm: BUG in pgtable_pmd_page_dtor
@ 2016-11-25 11:41 ` Andrey Ryabinin
0 siblings, 0 replies; 24+ messages in thread
From: Andrey Ryabinin @ 2016-11-25 11:41 UTC (permalink / raw)
To: Vlastimil Babka, Dmitry Vyukov, Andrew Morton
Cc: Kirill A. Shutemov, Michal Hocko, Ingo Molnar, Joonsoo Kim,
linux-mm@kvack.org, LKML, syzkaller
On 11/25/2016 11:42 AM, Vlastimil Babka wrote:
> pr_emerg("page:%p count:%d mapcount:%d mapping:%p index:%#lx",
> page, page_ref_count(page), mapcount,
> @@ -59,6 +61,21 @@ void __dump_page(struct page *page, const char *reason)
>
> pr_emerg("flags: %#lx(%pGp)\n", page->flags, &page->flags);
>
> + pr_alert("raw struct page data:");
> + for (i = 0; i < sizeof(struct page) / sizeof(unsigned long); i++) {
> + unsigned long *word_ptr;
> +
> + word_ptr = ((unsigned long *) page) + i;
> +
> + if ((i % words_per_line) == 0) {
> + pr_cont("\n");
> + pr_alert(" %016lx", *word_ptr);
> + } else {
> + pr_cont(" %016lx", *word_ptr);
> + }
> + }
> + pr_cont("\n");
> +
Single call to print_hex_dump() could replace this loop.
> if (reason)
> pr_alert("page dumped because: %s\n", reason);
>
>
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: mm: BUG in pgtable_pmd_page_dtor
2016-11-25 11:41 ` Andrey Ryabinin
@ 2016-11-25 12:58 ` Vlastimil Babka
-1 siblings, 0 replies; 24+ messages in thread
From: Vlastimil Babka @ 2016-11-25 12:58 UTC (permalink / raw)
To: Andrey Ryabinin, Dmitry Vyukov, Andrew Morton
Cc: Kirill A. Shutemov, Michal Hocko, Ingo Molnar, Joonsoo Kim,
linux-mm@kvack.org, LKML, syzkaller
On 11/25/2016 12:41 PM, Andrey Ryabinin wrote:
>
>
> On 11/25/2016 11:42 AM, Vlastimil Babka wrote:
>
>> pr_emerg("page:%p count:%d mapcount:%d mapping:%p index:%#lx",
>> page, page_ref_count(page), mapcount,
>> @@ -59,6 +61,21 @@ void __dump_page(struct page *page, const char *reason)
>>
>> pr_emerg("flags: %#lx(%pGp)\n", page->flags, &page->flags);
>>
>> + pr_alert("raw struct page data:");
>> + for (i = 0; i < sizeof(struct page) / sizeof(unsigned long); i++) {
>> + unsigned long *word_ptr;
>> +
>> + word_ptr = ((unsigned long *) page) + i;
>> +
>> + if ((i % words_per_line) == 0) {
>> + pr_cont("\n");
>> + pr_alert(" %016lx", *word_ptr);
>> + } else {
>> + pr_cont(" %016lx", *word_ptr);
>> + }
>> + }
>> + pr_cont("\n");
>> +
>
> Single call to print_hex_dump() could replace this loop.
Ah, didn't know about that one, thanks!
This also addresses Kirill's comment:
-----8<-----
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: mm: BUG in pgtable_pmd_page_dtor
@ 2016-11-25 12:58 ` Vlastimil Babka
0 siblings, 0 replies; 24+ messages in thread
From: Vlastimil Babka @ 2016-11-25 12:58 UTC (permalink / raw)
To: Andrey Ryabinin, Dmitry Vyukov, Andrew Morton
Cc: Kirill A. Shutemov, Michal Hocko, Ingo Molnar, Joonsoo Kim,
linux-mm@kvack.org, LKML, syzkaller
On 11/25/2016 12:41 PM, Andrey Ryabinin wrote:
>
>
> On 11/25/2016 11:42 AM, Vlastimil Babka wrote:
>
>> pr_emerg("page:%p count:%d mapcount:%d mapping:%p index:%#lx",
>> page, page_ref_count(page), mapcount,
>> @@ -59,6 +61,21 @@ void __dump_page(struct page *page, const char *reason)
>>
>> pr_emerg("flags: %#lx(%pGp)\n", page->flags, &page->flags);
>>
>> + pr_alert("raw struct page data:");
>> + for (i = 0; i < sizeof(struct page) / sizeof(unsigned long); i++) {
>> + unsigned long *word_ptr;
>> +
>> + word_ptr = ((unsigned long *) page) + i;
>> +
>> + if ((i % words_per_line) == 0) {
>> + pr_cont("\n");
>> + pr_alert(" %016lx", *word_ptr);
>> + } else {
>> + pr_cont(" %016lx", *word_ptr);
>> + }
>> + }
>> + pr_cont("\n");
>> +
>
> Single call to print_hex_dump() could replace this loop.
Ah, didn't know about that one, thanks!
This also addresses Kirill's comment:
-----8<-----
>From 417467521d0a68fb70dc2d5bd151524bf0c79437 Mon Sep 17 00:00:00 2001
From: Vlastimil Babka <vbabka@suse.cz>
Date: Fri, 25 Nov 2016 09:08:05 +0100
Subject: [PATCH] mm, debug: print raw struct page data in __dump_page()
The __dump_page() function is used when a page metadata inconsistency is
detected, either by standard runtime checks, or extra checks in CONFIG_DEBUG_VM
builds. It prints some of the relevant metadata, but not the whole struct page,
which is based on unions and interpretation is dependent on the context.
This means that sometimes e.g. a VM_BUG_ON_PAGE() checks certain field, which
is however not printed by __dump_page() and the resulting bug report may then
lack clues that could help in determining the root cause. This patch solves
the problem by simply printing the whole struct page word by word, so no part
is missing, but the interpretation of the data is left to developers. This is
similar to e.g. x86_64 raw stack dumps.
Example output:
page:ffffea00000475c0 count:1 mapcount:0 mapping: (null) index:0x0
flags: 0x100000000000400(reserved)
raw: 0100000000000400 0000000000000000 0000000000000000 00000001ffffffff
raw: ffffea00000475e0 ffffea00000475e0 0000000000000000 0000000000000000
page dumped because: VM_BUG_ON_PAGE(1)
[aryabinin@virtuozzo.com: suggested print_hex_dump()]
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
---
mm/debug.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/mm/debug.c b/mm/debug.c
index 9feb699c5d25..185c19bda078 100644
--- a/mm/debug.c
+++ b/mm/debug.c
@@ -59,6 +59,10 @@ void __dump_page(struct page *page, const char *reason)
pr_emerg("flags: %#lx(%pGp)\n", page->flags, &page->flags);
+ print_hex_dump(KERN_ALERT, "raw: ", DUMP_PREFIX_NONE,
+ 32, (sizeof(unsigned long) == 8) ? 8 : 4,
+ page, sizeof(struct page), false);
+
if (reason)
pr_alert("page dumped because: %s\n", reason);
--
2.10.2
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: mm: BUG in pgtable_pmd_page_dtor
2016-11-25 12:58 ` Vlastimil Babka
@ 2016-11-25 13:07 ` Kirill A. Shutemov
-1 siblings, 0 replies; 24+ messages in thread
From: Kirill A. Shutemov @ 2016-11-25 13:07 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Andrey Ryabinin, Dmitry Vyukov, Andrew Morton, Kirill A. Shutemov,
Michal Hocko, Ingo Molnar, Joonsoo Kim, linux-mm@kvack.org, LKML,
syzkaller
On Fri, Nov 25, 2016 at 01:58:57PM +0100, Vlastimil Babka wrote:
> On 11/25/2016 12:41 PM, Andrey Ryabinin wrote:
> >
> >
> > On 11/25/2016 11:42 AM, Vlastimil Babka wrote:
> >
> >> pr_emerg("page:%p count:%d mapcount:%d mapping:%p index:%#lx",
> >> page, page_ref_count(page), mapcount,
> >> @@ -59,6 +61,21 @@ void __dump_page(struct page *page, const char *reason)
> >>
> >> pr_emerg("flags: %#lx(%pGp)\n", page->flags, &page->flags);
> >>
> >> + pr_alert("raw struct page data:");
> >> + for (i = 0; i < sizeof(struct page) / sizeof(unsigned long); i++) {
> >> + unsigned long *word_ptr;
> >> +
> >> + word_ptr = ((unsigned long *) page) + i;
> >> +
> >> + if ((i % words_per_line) == 0) {
> >> + pr_cont("\n");
> >> + pr_alert(" %016lx", *word_ptr);
> >> + } else {
> >> + pr_cont(" %016lx", *word_ptr);
> >> + }
> >> + }
> >> + pr_cont("\n");
> >> +
> >
> > Single call to print_hex_dump() could replace this loop.
>
> Ah, didn't know about that one, thanks!
>
> This also addresses Kirill's comment:
>
> -----8<-----
> From 417467521d0a68fb70dc2d5bd151524bf0c79437 Mon Sep 17 00:00:00 2001
> From: Vlastimil Babka <vbabka@suse.cz>
> Date: Fri, 25 Nov 2016 09:08:05 +0100
> Subject: [PATCH] mm, debug: print raw struct page data in __dump_page()
>
> The __dump_page() function is used when a page metadata inconsistency is
> detected, either by standard runtime checks, or extra checks in CONFIG_DEBUG_VM
> builds. It prints some of the relevant metadata, but not the whole struct page,
> which is based on unions and interpretation is dependent on the context.
>
> This means that sometimes e.g. a VM_BUG_ON_PAGE() checks certain field, which
> is however not printed by __dump_page() and the resulting bug report may then
> lack clues that could help in determining the root cause. This patch solves
> the problem by simply printing the whole struct page word by word, so no part
> is missing, but the interpretation of the data is left to developers. This is
> similar to e.g. x86_64 raw stack dumps.
>
> Example output:
>
> page:ffffea00000475c0 count:1 mapcount:0 mapping: (null) index:0x0
> flags: 0x100000000000400(reserved)
> raw: 0100000000000400 0000000000000000 0000000000000000 00000001ffffffff
> raw: ffffea00000475e0 ffffea00000475e0 0000000000000000 0000000000000000
> page dumped because: VM_BUG_ON_PAGE(1)
>
> [aryabinin@virtuozzo.com: suggested print_hex_dump()]
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> ---
> mm/debug.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/mm/debug.c b/mm/debug.c
> index 9feb699c5d25..185c19bda078 100644
> --- a/mm/debug.c
> +++ b/mm/debug.c
> @@ -59,6 +59,10 @@ void __dump_page(struct page *page, const char *reason)
>
> pr_emerg("flags: %#lx(%pGp)\n", page->flags, &page->flags);
>
> + print_hex_dump(KERN_ALERT, "raw: ", DUMP_PREFIX_NONE,
> + 32, (sizeof(unsigned long) == 8) ? 8 : 4,
That's a very fancy way to write sizeof(unsigned long) ;)
--
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] 24+ messages in thread* Re: mm: BUG in pgtable_pmd_page_dtor
@ 2016-11-25 13:07 ` Kirill A. Shutemov
0 siblings, 0 replies; 24+ messages in thread
From: Kirill A. Shutemov @ 2016-11-25 13:07 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Andrey Ryabinin, Dmitry Vyukov, Andrew Morton, Kirill A. Shutemov,
Michal Hocko, Ingo Molnar, Joonsoo Kim, linux-mm@kvack.org, LKML,
syzkaller
On Fri, Nov 25, 2016 at 01:58:57PM +0100, Vlastimil Babka wrote:
> On 11/25/2016 12:41 PM, Andrey Ryabinin wrote:
> >
> >
> > On 11/25/2016 11:42 AM, Vlastimil Babka wrote:
> >
> >> pr_emerg("page:%p count:%d mapcount:%d mapping:%p index:%#lx",
> >> page, page_ref_count(page), mapcount,
> >> @@ -59,6 +61,21 @@ void __dump_page(struct page *page, const char *reason)
> >>
> >> pr_emerg("flags: %#lx(%pGp)\n", page->flags, &page->flags);
> >>
> >> + pr_alert("raw struct page data:");
> >> + for (i = 0; i < sizeof(struct page) / sizeof(unsigned long); i++) {
> >> + unsigned long *word_ptr;
> >> +
> >> + word_ptr = ((unsigned long *) page) + i;
> >> +
> >> + if ((i % words_per_line) == 0) {
> >> + pr_cont("\n");
> >> + pr_alert(" %016lx", *word_ptr);
> >> + } else {
> >> + pr_cont(" %016lx", *word_ptr);
> >> + }
> >> + }
> >> + pr_cont("\n");
> >> +
> >
> > Single call to print_hex_dump() could replace this loop.
>
> Ah, didn't know about that one, thanks!
>
> This also addresses Kirill's comment:
>
> -----8<-----
> From 417467521d0a68fb70dc2d5bd151524bf0c79437 Mon Sep 17 00:00:00 2001
> From: Vlastimil Babka <vbabka@suse.cz>
> Date: Fri, 25 Nov 2016 09:08:05 +0100
> Subject: [PATCH] mm, debug: print raw struct page data in __dump_page()
>
> The __dump_page() function is used when a page metadata inconsistency is
> detected, either by standard runtime checks, or extra checks in CONFIG_DEBUG_VM
> builds. It prints some of the relevant metadata, but not the whole struct page,
> which is based on unions and interpretation is dependent on the context.
>
> This means that sometimes e.g. a VM_BUG_ON_PAGE() checks certain field, which
> is however not printed by __dump_page() and the resulting bug report may then
> lack clues that could help in determining the root cause. This patch solves
> the problem by simply printing the whole struct page word by word, so no part
> is missing, but the interpretation of the data is left to developers. This is
> similar to e.g. x86_64 raw stack dumps.
>
> Example output:
>
> page:ffffea00000475c0 count:1 mapcount:0 mapping: (null) index:0x0
> flags: 0x100000000000400(reserved)
> raw: 0100000000000400 0000000000000000 0000000000000000 00000001ffffffff
> raw: ffffea00000475e0 ffffea00000475e0 0000000000000000 0000000000000000
> page dumped because: VM_BUG_ON_PAGE(1)
>
> [aryabinin@virtuozzo.com: suggested print_hex_dump()]
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> ---
> mm/debug.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/mm/debug.c b/mm/debug.c
> index 9feb699c5d25..185c19bda078 100644
> --- a/mm/debug.c
> +++ b/mm/debug.c
> @@ -59,6 +59,10 @@ void __dump_page(struct page *page, const char *reason)
>
> pr_emerg("flags: %#lx(%pGp)\n", page->flags, &page->flags);
>
> + print_hex_dump(KERN_ALERT, "raw: ", DUMP_PREFIX_NONE,
> + 32, (sizeof(unsigned long) == 8) ? 8 : 4,
That's a very fancy way to write sizeof(unsigned long) ;)
--
Kirill A. Shutemov
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: mm: BUG in pgtable_pmd_page_dtor
2016-11-25 13:07 ` Kirill A. Shutemov
@ 2016-11-25 14:08 ` Vlastimil Babka
-1 siblings, 0 replies; 24+ messages in thread
From: Vlastimil Babka @ 2016-11-25 14:08 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Andrey Ryabinin, Dmitry Vyukov, Andrew Morton, Kirill A. Shutemov,
Michal Hocko, Ingo Molnar, Joonsoo Kim, linux-mm@kvack.org, LKML,
syzkaller
On 11/25/2016 02:07 PM, Kirill A. Shutemov wrote:
>> --- a/mm/debug.c
>> +++ b/mm/debug.c
>> @@ -59,6 +59,10 @@ void __dump_page(struct page *page, const char *reason)
>>
>> pr_emerg("flags: %#lx(%pGp)\n", page->flags, &page->flags);
>>
>> + print_hex_dump(KERN_ALERT, "raw: ", DUMP_PREFIX_NONE,
>> + 32, (sizeof(unsigned long) == 8) ? 8 : 4,
>
> That's a very fancy way to write sizeof(unsigned long) ;)
Ah, damnit, thanks.
----8<----
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: mm: BUG in pgtable_pmd_page_dtor
@ 2016-11-25 14:08 ` Vlastimil Babka
0 siblings, 0 replies; 24+ messages in thread
From: Vlastimil Babka @ 2016-11-25 14:08 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Andrey Ryabinin, Dmitry Vyukov, Andrew Morton, Kirill A. Shutemov,
Michal Hocko, Ingo Molnar, Joonsoo Kim, linux-mm@kvack.org, LKML,
syzkaller
On 11/25/2016 02:07 PM, Kirill A. Shutemov wrote:
>> --- a/mm/debug.c
>> +++ b/mm/debug.c
>> @@ -59,6 +59,10 @@ void __dump_page(struct page *page, const char *reason)
>>
>> pr_emerg("flags: %#lx(%pGp)\n", page->flags, &page->flags);
>>
>> + print_hex_dump(KERN_ALERT, "raw: ", DUMP_PREFIX_NONE,
>> + 32, (sizeof(unsigned long) == 8) ? 8 : 4,
>
> That's a very fancy way to write sizeof(unsigned long) ;)
Ah, damnit, thanks.
----8<----
>From 08d2ee803567c13e3de7ce7e19338fe5286cc6b8 Mon Sep 17 00:00:00 2001
From: Vlastimil Babka <vbabka@suse.cz>
Date: Fri, 25 Nov 2016 09:08:05 +0100
Subject: [PATCH v3] mm, debug: print raw struct page data in __dump_page()
The __dump_page() function is used when a page metadata inconsistency is
detected, either by standard runtime checks, or extra checks in CONFIG_DEBUG_VM
builds. It prints some of the relevant metadata, but not the whole struct page,
which is based on unions and interpretation is dependent on the context.
This means that sometimes e.g. a VM_BUG_ON_PAGE() checks certain field, which
is however not printed by __dump_page() and the resulting bug report may then
lack clues that could help in determining the root cause. This patch solves
the problem by simply printing the whole struct page word by word, so no part
is missing, but the interpretation of the data is left to developers. This is
similar to e.g. x86_64 raw stack dumps.
Example output:
page:ffffea00000475c0 count:1 mapcount:0 mapping: (null) index:0x0
flags: 0x100000000000400(reserved)
raw: 0100000000000400 0000000000000000 0000000000000000 00000001ffffffff
raw: ffffea00000475e0 ffffea00000475e0 0000000000000000 0000000000000000
page dumped because: VM_BUG_ON_PAGE(1)
[aryabinin@virtuozzo.com: suggested print_hex_dump()]
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
---
mm/debug.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/mm/debug.c b/mm/debug.c
index 9feb699c5d25..db1cd26d8752 100644
--- a/mm/debug.c
+++ b/mm/debug.c
@@ -59,6 +59,10 @@ void __dump_page(struct page *page, const char *reason)
pr_emerg("flags: %#lx(%pGp)\n", page->flags, &page->flags);
+ print_hex_dump(KERN_ALERT, "raw: ", DUMP_PREFIX_NONE, 32,
+ sizeof(unsigned long), page,
+ sizeof(struct page), false);
+
if (reason)
pr_alert("page dumped because: %s\n", reason);
--
2.10.2
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: mm: BUG in pgtable_pmd_page_dtor
2016-11-25 14:08 ` Vlastimil Babka
@ 2016-11-25 14:15 ` Kirill A. Shutemov
-1 siblings, 0 replies; 24+ messages in thread
From: Kirill A. Shutemov @ 2016-11-25 14:15 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Andrey Ryabinin, Dmitry Vyukov, Andrew Morton, Kirill A. Shutemov,
Michal Hocko, Ingo Molnar, Joonsoo Kim, linux-mm@kvack.org, LKML,
syzkaller
On Fri, Nov 25, 2016 at 03:08:10PM +0100, Vlastimil Babka wrote:
> On 11/25/2016 02:07 PM, Kirill A. Shutemov wrote:
> >> --- a/mm/debug.c
> >> +++ b/mm/debug.c
> >> @@ -59,6 +59,10 @@ void __dump_page(struct page *page, const char *reason)
> >>
> >> pr_emerg("flags: %#lx(%pGp)\n", page->flags, &page->flags);
> >>
> >> + print_hex_dump(KERN_ALERT, "raw: ", DUMP_PREFIX_NONE,
> >> + 32, (sizeof(unsigned long) == 8) ? 8 : 4,
> >
> > That's a very fancy way to write sizeof(unsigned long) ;)
>
> Ah, damnit, thanks.
>
> ----8<----
> From 08d2ee803567c13e3de7ce7e19338fe5286cc6b8 Mon Sep 17 00:00:00 2001
> From: Vlastimil Babka <vbabka@suse.cz>
> Date: Fri, 25 Nov 2016 09:08:05 +0100
> Subject: [PATCH v3] mm, debug: print raw struct page data in __dump_page()
>
> The __dump_page() function is used when a page metadata inconsistency is
> detected, either by standard runtime checks, or extra checks in CONFIG_DEBUG_VM
> builds. It prints some of the relevant metadata, but not the whole struct page,
> which is based on unions and interpretation is dependent on the context.
>
> This means that sometimes e.g. a VM_BUG_ON_PAGE() checks certain field, which
> is however not printed by __dump_page() and the resulting bug report may then
> lack clues that could help in determining the root cause. This patch solves
> the problem by simply printing the whole struct page word by word, so no part
> is missing, but the interpretation of the data is left to developers. This is
> similar to e.g. x86_64 raw stack dumps.
>
> Example output:
>
> page:ffffea00000475c0 count:1 mapcount:0 mapping: (null) index:0x0
> flags: 0x100000000000400(reserved)
> raw: 0100000000000400 0000000000000000 0000000000000000 00000001ffffffff
> raw: ffffea00000475e0 ffffea00000475e0 0000000000000000 0000000000000000
> page dumped because: VM_BUG_ON_PAGE(1)
>
> [aryabinin@virtuozzo.com: suggested print_hex_dump()]
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
--
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] 24+ messages in thread* Re: mm: BUG in pgtable_pmd_page_dtor
@ 2016-11-25 14:15 ` Kirill A. Shutemov
0 siblings, 0 replies; 24+ messages in thread
From: Kirill A. Shutemov @ 2016-11-25 14:15 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Andrey Ryabinin, Dmitry Vyukov, Andrew Morton, Kirill A. Shutemov,
Michal Hocko, Ingo Molnar, Joonsoo Kim, linux-mm@kvack.org, LKML,
syzkaller
On Fri, Nov 25, 2016 at 03:08:10PM +0100, Vlastimil Babka wrote:
> On 11/25/2016 02:07 PM, Kirill A. Shutemov wrote:
> >> --- a/mm/debug.c
> >> +++ b/mm/debug.c
> >> @@ -59,6 +59,10 @@ void __dump_page(struct page *page, const char *reason)
> >>
> >> pr_emerg("flags: %#lx(%pGp)\n", page->flags, &page->flags);
> >>
> >> + print_hex_dump(KERN_ALERT, "raw: ", DUMP_PREFIX_NONE,
> >> + 32, (sizeof(unsigned long) == 8) ? 8 : 4,
> >
> > That's a very fancy way to write sizeof(unsigned long) ;)
>
> Ah, damnit, thanks.
>
> ----8<----
> From 08d2ee803567c13e3de7ce7e19338fe5286cc6b8 Mon Sep 17 00:00:00 2001
> From: Vlastimil Babka <vbabka@suse.cz>
> Date: Fri, 25 Nov 2016 09:08:05 +0100
> Subject: [PATCH v3] mm, debug: print raw struct page data in __dump_page()
>
> The __dump_page() function is used when a page metadata inconsistency is
> detected, either by standard runtime checks, or extra checks in CONFIG_DEBUG_VM
> builds. It prints some of the relevant metadata, but not the whole struct page,
> which is based on unions and interpretation is dependent on the context.
>
> This means that sometimes e.g. a VM_BUG_ON_PAGE() checks certain field, which
> is however not printed by __dump_page() and the resulting bug report may then
> lack clues that could help in determining the root cause. This patch solves
> the problem by simply printing the whole struct page word by word, so no part
> is missing, but the interpretation of the data is left to developers. This is
> similar to e.g. x86_64 raw stack dumps.
>
> Example output:
>
> page:ffffea00000475c0 count:1 mapcount:0 mapping: (null) index:0x0
> flags: 0x100000000000400(reserved)
> raw: 0100000000000400 0000000000000000 0000000000000000 00000001ffffffff
> raw: ffffea00000475e0 ffffea00000475e0 0000000000000000 0000000000000000
> page dumped because: VM_BUG_ON_PAGE(1)
>
> [aryabinin@virtuozzo.com: suggested print_hex_dump()]
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
--
Kirill A. Shutemov
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: mm: BUG in pgtable_pmd_page_dtor
2016-11-25 14:08 ` Vlastimil Babka
@ 2016-11-25 16:03 ` Andrey Ryabinin
-1 siblings, 0 replies; 24+ messages in thread
From: Andrey Ryabinin @ 2016-11-25 16:03 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Kirill A. Shutemov, Dmitry Vyukov, Andrew Morton,
Kirill A. Shutemov, Michal Hocko, Ingo Molnar, Joonsoo Kim,
linux-mm@kvack.org, LKML, syzkaller
On 11/25/2016 05:08 PM, Vlastimil Babka wrote:
> On 11/25/2016 02:07 PM, Kirill A. Shutemov wrote:
>>> --- a/mm/debug.c
>>> +++ b/mm/debug.c
>>> @@ -59,6 +59,10 @@ void __dump_page(struct page *page, const char *reason)
>>>
>>> pr_emerg("flags: %#lx(%pGp)\n", page->flags, &page->flags);
>>>
>>> + print_hex_dump(KERN_ALERT, "raw: ", DUMP_PREFIX_NONE,
>>> + 32, (sizeof(unsigned long) == 8) ? 8 : 4,
>>
>> That's a very fancy way to write sizeof(unsigned long) ;)
>
> Ah, damnit, thanks.
>
> ----8<----
> From 08d2ee803567c13e3de7ce7e19338fe5286cc6b8 Mon Sep 17 00:00:00 2001
> From: Vlastimil Babka <vbabka@suse.cz>
> Date: Fri, 25 Nov 2016 09:08:05 +0100
> Subject: [PATCH v3] mm, debug: print raw struct page data in __dump_page()
>
> The __dump_page() function is used when a page metadata inconsistency is
> detected, either by standard runtime checks, or extra checks in CONFIG_DEBUG_VM
> builds. It prints some of the relevant metadata, but not the whole struct page,
> which is based on unions and interpretation is dependent on the context.
>
> This means that sometimes e.g. a VM_BUG_ON_PAGE() checks certain field, which
> is however not printed by __dump_page() and the resulting bug report may then
> lack clues that could help in determining the root cause. This patch solves
> the problem by simply printing the whole struct page word by word, so no part
> is missing, but the interpretation of the data is left to developers. This is
> similar to e.g. x86_64 raw stack dumps.
>
> Example output:
>
> page:ffffea00000475c0 count:1 mapcount:0 mapping: (null) index:0x0
> flags: 0x100000000000400(reserved)
> raw: 0100000000000400 0000000000000000 0000000000000000 00000001ffffffff
> raw: ffffea00000475e0 ffffea00000475e0 0000000000000000 0000000000000000
> page dumped because: VM_BUG_ON_PAGE(1)
>
> [aryabinin@virtuozzo.com: suggested print_hex_dump()]
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
--
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] 24+ messages in thread* Re: mm: BUG in pgtable_pmd_page_dtor
@ 2016-11-25 16:03 ` Andrey Ryabinin
0 siblings, 0 replies; 24+ messages in thread
From: Andrey Ryabinin @ 2016-11-25 16:03 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Kirill A. Shutemov, Dmitry Vyukov, Andrew Morton,
Kirill A. Shutemov, Michal Hocko, Ingo Molnar, Joonsoo Kim,
linux-mm@kvack.org, LKML, syzkaller
On 11/25/2016 05:08 PM, Vlastimil Babka wrote:
> On 11/25/2016 02:07 PM, Kirill A. Shutemov wrote:
>>> --- a/mm/debug.c
>>> +++ b/mm/debug.c
>>> @@ -59,6 +59,10 @@ void __dump_page(struct page *page, const char *reason)
>>>
>>> pr_emerg("flags: %#lx(%pGp)\n", page->flags, &page->flags);
>>>
>>> + print_hex_dump(KERN_ALERT, "raw: ", DUMP_PREFIX_NONE,
>>> + 32, (sizeof(unsigned long) == 8) ? 8 : 4,
>>
>> That's a very fancy way to write sizeof(unsigned long) ;)
>
> Ah, damnit, thanks.
>
> ----8<----
> From 08d2ee803567c13e3de7ce7e19338fe5286cc6b8 Mon Sep 17 00:00:00 2001
> From: Vlastimil Babka <vbabka@suse.cz>
> Date: Fri, 25 Nov 2016 09:08:05 +0100
> Subject: [PATCH v3] mm, debug: print raw struct page data in __dump_page()
>
> The __dump_page() function is used when a page metadata inconsistency is
> detected, either by standard runtime checks, or extra checks in CONFIG_DEBUG_VM
> builds. It prints some of the relevant metadata, but not the whole struct page,
> which is based on unions and interpretation is dependent on the context.
>
> This means that sometimes e.g. a VM_BUG_ON_PAGE() checks certain field, which
> is however not printed by __dump_page() and the resulting bug report may then
> lack clues that could help in determining the root cause. This patch solves
> the problem by simply printing the whole struct page word by word, so no part
> is missing, but the interpretation of the data is left to developers. This is
> similar to e.g. x86_64 raw stack dumps.
>
> Example output:
>
> page:ffffea00000475c0 count:1 mapcount:0 mapping: (null) index:0x0
> flags: 0x100000000000400(reserved)
> raw: 0100000000000400 0000000000000000 0000000000000000 00000001ffffffff
> raw: ffffea00000475e0 ffffea00000475e0 0000000000000000 0000000000000000
> page dumped because: VM_BUG_ON_PAGE(1)
>
> [aryabinin@virtuozzo.com: suggested print_hex_dump()]
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
^ permalink raw reply [flat|nested] 24+ messages in thread