From: Jia He <hejianet@gmail.com>
To: Daniel Vacek <neelx@redhat.com>
Cc: open list <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org, Sudeep Holla <sudeep.holla@arm.com>,
Naresh Kamboju <naresh.kamboju@linaro.org>,
Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@techsingularity.net>,
Michal Hocko <mhocko@suse.com>,
Paul Burton <paul.burton@imgtec.com>,
Pavel Tatashin <pasha.tatashin@oracle.com>,
Vlastimil Babka <vbabka@suse.cz>, stable <stable@vger.kernel.org>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [PATCH] mm/page_alloc: fix boot hang in memmap_init_zone
Date: Fri, 16 Mar 2018 08:45:32 +0800 [thread overview]
Message-ID: <b391f698-5619-4946-bac7-5ba39628335e@gmail.com> (raw)
In-Reply-To: <CACjP9X_01nuv86WeETjOFgNYQkvUFaE8089yX9fgq9uB8zpPTQ@mail.gmail.com>
On 3/15/2018 11:39 PM, Daniel Vacek Wrote:
> On Thu, Mar 15, 2018 at 3:08 PM, Jia He <hejianet@gmail.com> wrote:
>> Hi Daniel
>>
>>
>>
>> On 3/14/2018 6:42 AM, Daniel Vacek Wrote:
>>> On some architectures (reported on arm64) commit 864b75f9d6b01
>>> ("mm/page_alloc: fix memmap_init_zone pageblock alignment")
>>> causes a boot hang. This patch fixes the hang making sure the alignment
>>> never steps back.
>>>
>>> Link:
>>> http://lkml.kernel.org/r/0485727b2e82da7efbce5f6ba42524b429d0391a.1520011945.git.neelx@redhat.com
>>> Fixes: 864b75f9d6b01 ("mm/page_alloc: fix memmap_init_zone pageblock
>>> alignment")
>>> Signed-off-by: Daniel Vacek <neelx@redhat.com>
>>> Tested-by: Sudeep Holla <sudeep.holla@arm.com>
>>> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org>
>>> Cc: Andrew Morton <akpm@linux-foundation.org>
>>> Cc: Mel Gorman <mgorman@techsingularity.net>
>>> Cc: Michal Hocko <mhocko@suse.com>
>>> Cc: Paul Burton <paul.burton@imgtec.com>
>>> Cc: Pavel Tatashin <pasha.tatashin@oracle.com>
>>> Cc: Vlastimil Babka <vbabka@suse.cz>
>>> Cc: <stable@vger.kernel.org>
>>> ---
>>> mm/page_alloc.c | 7 ++++++-
>>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>>> index 3d974cb2a1a1..e033a6895c6f 100644
>>> --- a/mm/page_alloc.c
>>> +++ b/mm/page_alloc.c
>>> @@ -5364,9 +5364,14 @@ void __meminit memmap_init_zone(unsigned long size,
>>> int nid, unsigned long zone,
>>> * is not. move_freepages_block() can shift ahead
>>> of
>>> * the valid region but still depends on correct
>>> page
>>> * metadata.
>>> + * Also make sure we never step back.
>>> */
>>> - pfn = (memblock_next_valid_pfn(pfn, end_pfn) &
>>> + unsigned long next_pfn;
>>> +
>>> + next_pfn = (memblock_next_valid_pfn(pfn, end_pfn)
>>> &
>>> ~(pageblock_nr_pages-1)) - 1;
>>> + if (next_pfn > pfn)
>>> + pfn = next_pfn;
>> It didn't resolve the booting hang issue in my arm64 server.
>> what if memblock_next_valid_pfn(pfn, end_pfn) is 32 and pageblock_nr_pages
>> is 8196?
>> Thus, next_pfn will be (unsigned long)-1 and be larger than pfn.
>> So still there is an infinite loop here.
> Hi Jia,
>
> Yeah, looks like another uncovered case. Noone reported this so far.
> Anyways upstream reverted all this for now and we're discussing the
> right approach here.
>
> In any case thanks for this report. Can you share something like below
> from your machine?
sure.
[ 0.000000] NUMA: Faking a node at [mem
0x0000000000000000-0x00000017ffffffff]
[ 0.000000] NUMA: NODE_DATA [mem 0x17ffffcb80-0x17ffffffff]
[ 0.000000] Zone ranges:
[ 0.000000] DMA32 [mem 0x0000000000200000-0x00000000ffffffff]
[ 0.000000] Normal [mem 0x0000000100000000-0x00000017ffffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000200000-0x000000000021ffff]
[ 0.000000] node 0: [mem 0x0000000000820000-0x000000000307ffff]
[ 0.000000] node 0: [mem 0x0000000003080000-0x000000000308ffff]
[ 0.000000] node 0: [mem 0x0000000003090000-0x00000000031fffff]
[ 0.000000] node 0: [mem 0x0000000003200000-0x00000000033fffff]
[ 0.000000] node 0: [mem 0x0000000003410000-0x000000000563ffff]
[ 0.000000] node 0: [mem 0x0000000005640000-0x000000000567ffff]
[ 0.000000] node 0: [mem 0x0000000005680000-0x00000000056dffff]
[ 0.000000] node 0: [mem 0x00000000056e0000-0x00000000086fffff]
[ 0.000000] node 0: [mem 0x0000000008700000-0x000000000871ffff]
[ 0.000000] node 0: [mem 0x0000000008720000-0x000000000894ffff]
[ 0.000000] node 0: [mem 0x0000000008950000-0x0000000008baffff]
[ 0.000000] node 0: [mem 0x0000000008bb0000-0x0000000008bcffff]
[ 0.000000] node 0: [mem 0x0000000008bd0000-0x0000000008c4ffff]
[ 0.000000] node 0: [mem 0x0000000008c50000-0x0000000008e2ffff]
[ 0.000000] node 0: [mem 0x0000000008e30000-0x0000000008e4ffff]
[ 0.000000] node 0: [mem 0x0000000008e50000-0x0000000008fcffff]
[ 0.000000] node 0: [mem 0x0000000008fd0000-0x000000000910ffff]
[ 0.000000] node 0: [mem 0x0000000009110000-0x00000000092effff]
[ 0.000000] node 0: [mem 0x00000000092f0000-0x000000000930ffff]
[ 0.000000] node 0: [mem 0x0000000009310000-0x000000000963ffff]
[ 0.000000] node 0: [mem 0x0000000009640000-0x000000000e61ffff]
[ 0.000000] node 0: [mem 0x000000000e620000-0x000000000e64ffff]
[ 0.000000] node 0: [mem 0x000000000e650000-0x000000000fffffff]
[ 0.000000] node 0: [mem 0x0000000010800000-0x0000000017feffff]
[ 0.000000] node 0: [mem 0x000000001c000000-0x000000001c00ffff]
[ 0.000000] node 0: [mem 0x000000001c010000-0x000000001c7fffff]
[ 0.000000] node 0: [mem 0x000000001c810000-0x000000007efbffff]
[ 0.000000] node 0: [mem 0x000000007efc0000-0x000000007efdffff]
[ 0.000000] node 0: [mem 0x000000007efe0000-0x000000007efeffff]
[ 0.000000] node 0: [mem 0x000000007eff0000-0x000000007effffff]
[ 0.000000] node 0: [mem 0x000000007f000000-0x00000017ffffffff]
[ 0.000000] Initmem setup node 0 [mem
0x0000000000200000-0x00000017ffffffff]
--
Cheers,
Jia
prev parent reply other threads:[~2018-03-16 0:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-13 22:42 Daniel Vacek
2018-03-14 14:17 ` Michal Hocko
2018-03-15 1:30 ` Daniel Vacek
2018-03-15 11:50 ` Michal Hocko
2018-03-15 14:53 ` Daniel Vacek
2018-03-15 14:08 ` Jia He
2018-03-15 15:39 ` Daniel Vacek
2018-03-16 0:45 ` Jia He [this message]
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=b391f698-5619-4946-bac7-5ba39628335e@gmail.com \
--to=hejianet@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=ard.biesheuvel@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@suse.com \
--cc=naresh.kamboju@linaro.org \
--cc=neelx@redhat.com \
--cc=pasha.tatashin@oracle.com \
--cc=paul.burton@imgtec.com \
--cc=stable@vger.kernel.org \
--cc=sudeep.holla@arm.com \
--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
all inboxes | Powered by JetHome®