From: Michal Hocko <mhocko@suse.com>
To: Qian Cai <cai@lca.pw>
Cc: akpm@linux-foundation.org, osalvador@suse.de,
catalin.marinas@arm.com, vbabka@suse.cz, linux-mm@kvack.org
Subject: Re: [PATCH] mm/hotplug: invalid PFNs from pfn_to_online_page()
Date: Mon, 21 Jan 2019 19:36:13 +0100 [thread overview]
Message-ID: <20190121183613.GY4087@dhcp22.suse.cz> (raw)
In-Reply-To: <3c4aa744-4a8a-08a6-bc41-ac3a722a0d17@lca.pw>
On Mon 21-01-19 12:58:46, Qian Cai wrote:
>
>
> On 1/21/19 11:38 AM, Qian Cai wrote:
> >
> >
> > On 1/21/19 4:53 AM, Michal Hocko wrote:
> >> On Thu 17-01-19 21:16:50, Qian Cai wrote:
> >>> On an arm64 ThunderX2 server, the first kmemleak scan would crash [1]
> >>> with CONFIG_DEBUG_VM_PGFLAGS=y due to page_to_nid() found a pfn that is
> >>> not directly mapped (MEMBLOCK_NOMAP). Hence, the page->flags is
> >>> uninitialized.
> >>>
> >>> This is due to the commit 9f1eb38e0e11 ("mm, kmemleak: little
> >>> optimization while scanning") starts to use pfn_to_online_page() instead
> >>> of pfn_valid(). However, in the CONFIG_MEMORY_HOTPLUG=y case,
> >>> pfn_to_online_page() does not call memblock_is_map_memory() while
> >>> pfn_valid() does.
> >>
> >> How come there is an online section which has an pfn_valid==F? We do
> >> allocate the full section worth of struct pages so there is a valid
> >> struct page. Is there any hole inside this section?
> >
> > It has CONFIG_HOLES_IN_ZONE=y.
>
> Actually, this does not seem have anything to do with holes.
>
> 68709f45385a arm64: only consider memblocks with NOMAP cleared for linear mapping
>
> This causes pages marked as nomap being no long reassigned to the new zone in
> memmap_init_zone() by calling __init_single_page().
Thanks for the pointer. This sched some light but I cannot say I would
understand all the details.
> There is an old discussion for this topic.
> https://lkml.org/lkml/2016/11/30/566
Hmm, I see. The documentation is not the best (mea culpa)
* Return page for the valid pfn only if the page is online. All pfn
* walkers which rely on the fully initialized page->flags and others
* should use this rather than pfn_valid && pfn_to_page
This suggests that the pfn is _valid_ when using pfn_to_online_page and
some callers indeed do so. Some of them don't though which is probably
because the later part of the documentation suggests that it should
replace pfn_valid & pfn_to_page. Thinking about this more, I guess we do
not want to put an additional burden on callers and require pfn_valid to
be called as well. This is just error prone and can lead to problems
like this one.
So I agree with your change (modulo the range check) but please make
sure to make all this information to the changelog.
Thanks!
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2019-01-21 18:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-17 17:36 kmemleak scan crash due to invalid PFNs Qian Cai
2019-01-17 18:50 ` Oscar Salvador
2019-01-17 18:50 ` Oscar Salvador
2019-01-17 18:58 ` Oscar Salvador
2019-01-18 2:16 ` [PATCH] mm/hotplug: invalid PFNs from pfn_to_online_page() Qian Cai
2019-01-21 9:53 ` Michal Hocko
2019-01-21 16:38 ` Qian Cai
2019-01-21 17:58 ` Qian Cai
2019-01-21 18:36 ` Michal Hocko [this message]
2019-01-21 18:19 ` Michal Hocko
2019-01-21 18:37 ` Qian Cai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190121183613.GY4087@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=cai@lca.pw \
--cc=catalin.marinas@arm.com \
--cc=linux-mm@kvack.org \
--cc=osalvador@suse.de \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox