[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9f884d5c-ca60-dc7b-219c-c081c755fab6@suse.cz>
Date: Tue, 14 Jan 2020 13:04:31 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Michal Hocko <mhocko@...nel.org>, linux-mm@...ck.org,
Andrew Morton <akpm@...ux-foundation.org>
Cc: Anshuman Khandual <anshuman.khandual@....com>,
David Hildenbrand <david@...hat.com>, Qian Cai <cai@....pw>,
Oscar Salvador <osalvador@...e.de>,
Mel Gorman <mgorman@...hsingularity.net>,
Mike Rapoport <rppt@...ux.ibm.com>,
Dan Williams <dan.j.williams@...el.com>,
Pavel Tatashin <pavel.tatashin@...rosoft.com>,
linux-kernel@...r.kernel.org, Ralph Campbell <rcampbell@...dia.com>
Subject: [PATCH] mm, debug: always print flags in dump_page()
On 1/14/20 12:32 PM, Michal Hocko wrote:
> On Tue 14-01-20 11:23:52, Vlastimil Babka wrote:
>> On 1/14/20 10:10 AM, Michal Hocko wrote:
>> > [Cc Ralph]
>> >> The reason is dump_page() does not print page->flags universally
>> >> and only does so for KSM, Anon and File pages while excluding
>> >> reserved pages at boot. Wondering should not we make printing
>> >> page->flags universal ?
>> >
>> > We used to do that and this caught me as a surprise when looking again.
>> > This is a result of 76a1850e4572 ("mm/debug.c: __dump_page() prints an
>> > extra line") which is a cleanup patch and I suspect this result was not
>> > anticipated.
>> >
>> > The following will do the trick but I cannot really say I like the code
>> > duplication. pr_cont in this case sounds like a much cleaner solution to
>> > me.
>>
>> How about this then?
>
> Yes makes sense as well.
Ok here's a proper formatted patch
----8<----
>From 7b673c45bc16526586ae8ea6fba416a547baa04e Mon Sep 17 00:00:00 2001
From: Vlastimil Babka <vbabka@...e.cz>
Date: Tue, 14 Jan 2020 12:52:48 +0100
Subject: [PATCH] mm, debug: always print flags in dump_page()
Commit 76a1850e4572 ("mm/debug.c: __dump_page() prints an extra line")
inadvertently removed printing of page flags for pages that are neither
anon nor ksm nor have a mapping. Fix that.
Using pr_cont() again would be a solution, but the commit explicitly removed
its use. Avoiding the danger of mixing up split lines from multiple CPUs might
be beneficial for near-panic dumps like this, so fix this without reintroducing
pr_cont().
Reported-by: Anshuman Khandual <anshuman.khandual@....com>
Reported-by: Michal Hocko <mhocko@...nel.org>
Fixes: 76a1850e4572 ("mm/debug.c: __dump_page() prints an extra line")
Signed-off-by: Vlastimil Babka <vbabka@...e.cz>
---
mm/debug.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/mm/debug.c b/mm/debug.c
index 0461df1207cb..6a52316af839 100644
--- a/mm/debug.c
+++ b/mm/debug.c
@@ -47,6 +47,7 @@ void __dump_page(struct page *page, const char *reason)
struct address_space *mapping;
bool page_poisoned = PagePoisoned(page);
int mapcount;
+ char *type = "";
/*
* If struct page is poisoned don't access Page*() functions as that
@@ -78,9 +79,9 @@ void __dump_page(struct page *page, const char *reason)
page, page_ref_count(page), mapcount,
page->mapping, page_to_pgoff(page));
if (PageKsm(page))
- pr_warn("ksm flags: %#lx(%pGp)\n", page->flags, &page->flags);
+ type = "ksm ";
else if (PageAnon(page))
- pr_warn("anon flags: %#lx(%pGp)\n", page->flags, &page->flags);
+ type = "anon ";
else if (mapping) {
if (mapping->host && mapping->host->i_dentry.first) {
struct dentry *dentry;
@@ -88,10 +89,11 @@ void __dump_page(struct page *page, const char *reason)
pr_warn("%ps name:\"%pd\"\n", mapping->a_ops, dentry);
} else
pr_warn("%ps\n", mapping->a_ops);
- pr_warn("flags: %#lx(%pGp)\n", page->flags, &page->flags);
}
BUILD_BUG_ON(ARRAY_SIZE(pageflag_names) != __NR_PAGEFLAGS + 1);
+ pr_warn("%sflags: %#lx(%pGp)\n", type, page->flags, &page->flags);
+
hex_only:
print_hex_dump(KERN_WARNING, "raw: ", DUMP_PREFIX_NONE, 32,
sizeof(unsigned long), page,
--
2.24.1
Powered by blists - more mailing lists