From: Patrick Daly <quic_pdaly@quicinc.com>
To: <linux-mm@kvack.org>, <linux-arm-kernel@lists.infradead.org>,
<mhocko@suse.com>
Subject: Race condition in build_all_zonelists() when offlining movable zone
Date: Tue, 16 Aug 2022 20:42:50 -0700 [thread overview]
Message-ID: <20220817034250.GB2473@hu-pdaly-lv.qualcomm.com> (raw)
System: arm64 with 5.15 based kernel. CONFIG_NUMA=n.
NODE_DATA(nid)->node_zonelists[ZONELIST_FALLBACK] - before offline operation
[0] - ZONE_MOVABLE
[1] - ZONE_NORMAL
[2] - NULL
For a GFP_KERNEL allocation, alloc_pages_slowpath() will save the offset of
ZONE_NORMAL in ac->preferred_zoneref. If a concurrent memory_offline operation
removes the last page from ZONE_MOVABLE, build_all_zonelists() &
build_zonerefs_node() will update node_zonelists as shown below. Only
populated zones are added.
NODE_DATA(nid)->node_zonelists[ZONELIST_FALLBACK] - after offline operation
[0] - ZONE_NORMAL
[1] - NULL
[2] - NULL
The thread in alloc_pages_slowpath() will call get_page_from_freelist()
repeatedly to allocate from the zones in zonelist beginning from
preferred_zoneref. Since this is now NULL, it will never succeed, and OOM
killer will kill all killable processes.
I noticed a comment on a recent change bb7645c33869
("mm, page_alloc: fix build_zonerefs_node()") which appeared to be relevant,
but later replies indicated concerns with performance implications.
https://lore.kernel.org/linux-mm/Yk7NqTlw7lmFzpKb@dhcp22.suse.cz/
next reply other threads:[~2022-08-17 3:42 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-17 3:42 Patrick Daly [this message]
[not found] ` <YvyM1AWeJRt6PF9B@dhcp22.suse.cz>
[not found] ` <YvyRvxO+FHMyuGn3@dhcp22.suse.cz>
[not found] ` <20220817104028.uin7cmkb4qlpgfbi@suse.de>
[not found] ` <YvzI0PHW6uojk+N1@dhcp22.suse.cz>
[not found] ` <20220817112647.z7wenwjpyt3hphtk@suse.de>
2022-08-19 2:11 ` Patrick Daly
2022-08-22 20:18 ` Patrick Daly
2022-08-23 6:36 ` David Hildenbrand
[not found] ` <20220823083349.5c2aolc6xgfhp3k7@suse.de>
2022-08-23 8:52 ` David Hildenbrand
2022-08-23 9:49 ` Mel Gorman
2022-08-23 10:34 ` David Hildenbrand
[not found] ` <20220823110946.o3eawk3kghaykcim@suse.de>
2022-08-23 12:18 ` Michal Hocko
[not found] ` <20220823125850.o3nhkmikmv7vyxq4@suse.de>
2022-08-23 13:25 ` Michal Hocko
2022-08-23 13:50 ` David Hildenbrand
2022-08-23 13:57 ` Michal Hocko
2022-08-23 15:14 ` Mel Gorman
2022-08-23 15:38 ` Michal Hocko
2022-08-23 15:51 ` David Hildenbrand
2022-08-24 9:45 ` Mel Gorman
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=20220817034250.GB2473@hu-pdaly-lv.qualcomm.com \
--to=quic_pdaly@quicinc.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
/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