From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
To: David Hildenbrand <david@redhat.com>, linux-kernel@vger.kernel.org
Cc: linux-mm@kvack.org, David Hildenbrand <david@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Oscar Salvador <osalvador@suse.de>,
Michal Hocko <mhocko@suse.com>,
Pavel Tatashin <pasha.tatashin@soleen.com>,
Dan Williams <dan.j.williams@intel.com>
Subject: Re: [PATCH v4 2/8] mm/memory_hotplug: Don't access uninitialized memmaps in shrink_zone_span()
Date: Thu, 26 Sep 2019 14:42:50 +0530 [thread overview]
Message-ID: <87wodvo1yl.fsf@linux.ibm.com> (raw)
In-Reply-To: <20190830091428.18399-3-david@redhat.com>
David Hildenbrand <david@redhat.com> writes:
> Let's limit shrinking to !ZONE_DEVICE so we can fix the current code. We
> should never try to touch the memmap of offline sections where we could
> have uninitialized memmaps and could trigger BUGs when calling
> page_to_nid() on poisoned pages.
>
> Stopping to shrink the ZONE_DEVICE is fine as set_zone_contiguous() cannot
> deal with ZONE_DEVICE either way. The zones will always be !contiguous
> already and zone shrinking is therefore of limited use.
Can you add more details w.r.t ZONE_DEVICE?
>
> Before commit d0dc12e86b31 ("mm/memory_hotplug: optimize memory
> hotplug"), the memmap was initialized with 0 and the node with the
> right value. So the zone might be wrong but not garbage. After that
> commit, both the zone and the node will be garbage when touching
> uninitialized memmaps.
>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Oscar Salvador <osalvador@suse.de>
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Fixes: d0dc12e86b31 ("mm/memory_hotplug: optimize memory hotplug")
> Reported-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
> mm/memory_hotplug.c | 14 +++++++++++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index ddba8d786e4a..e0d1f6a9dfeb 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -331,7 +331,7 @@ static unsigned long find_smallest_section_pfn(int nid, struct zone *zone,
> unsigned long end_pfn)
> {
> for (; start_pfn < end_pfn; start_pfn += PAGES_PER_SUBSECTION) {
> - if (unlikely(!pfn_valid(start_pfn)))
> + if (unlikely(!pfn_to_online_page(start_pfn)))
> continue;
>
> if (unlikely(pfn_to_nid(start_pfn) != nid))
> @@ -356,7 +356,7 @@ static unsigned long find_biggest_section_pfn(int nid, struct zone *zone,
> /* pfn is the end pfn of a memory section. */
> pfn = end_pfn - 1;
> for (; pfn >= start_pfn; pfn -= PAGES_PER_SUBSECTION) {
> - if (unlikely(!pfn_valid(pfn)))
> + if (unlikely(!pfn_to_online_page(pfn)))
> continue;
>
> if (unlikely(pfn_to_nid(pfn) != nid))
> @@ -415,7 +415,7 @@ static void shrink_zone_span(struct zone *zone, unsigned long start_pfn,
> */
> pfn = zone_start_pfn;
> for (; pfn < zone_end_pfn; pfn += PAGES_PER_SUBSECTION) {
> - if (unlikely(!pfn_valid(pfn)))
> + if (unlikely(!pfn_to_online_page(pfn)))
> continue;
>
> if (page_zone(pfn_to_page(pfn)) != zone)
> @@ -463,6 +463,14 @@ static void __remove_zone(struct zone *zone, unsigned long start_pfn,
> struct pglist_data *pgdat = zone->zone_pgdat;
> unsigned long flags;
>
> + /*
> + * Zone shrinking code cannot properly deal with ZONE_DEVICE. So
> + * we will not try to shrink the zones - which is okay as
> + * set_zone_contiguous() cannot deal with ZONE_DEVICE either way.
> + */
> + if (zone_idx(zone) == ZONE_DEVICE)
> + return;
Can you describe here what is special about ZONE_DEVICE?
> pgdat_resize_lock(zone->zone_pgdat, &flags);
> shrink_zone_span(zone, start_pfn, start_pfn + nr_pages);
> update_pgdat_span(pgdat);
> --
> 2.21.0
next prev parent reply other threads:[~2019-09-26 9:13 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-30 9:14 [PATCH v4 0/8] mm/memory_hotplug: Shrink zones before removing memory David Hildenbrand
2019-08-30 9:14 ` [PATCH v4 1/8] mm/memory_hotplug: Don't access uninitialized memmaps in shrink_pgdat_span() David Hildenbrand
2019-08-30 9:14 ` [PATCH v4 2/8] mm/memory_hotplug: Don't access uninitialized memmaps in shrink_zone_span() David Hildenbrand
2019-09-26 9:12 ` Aneesh Kumar K.V [this message]
2019-09-26 9:22 ` David Hildenbrand
2019-08-30 9:14 ` [PATCH v4 3/8] mm/memory_hotplug: Shrink zones when offlining memory David Hildenbrand
2019-08-30 9:14 ` David Hildenbrand
2019-08-30 9:14 ` [PATCH v4 4/8] mm/memory_hotplug: Poison memmap in remove_pfn_range_from_zone() David Hildenbrand
2019-09-26 9:10 ` Aneesh Kumar K.V
2019-09-26 9:14 ` David Hildenbrand
2019-08-30 9:14 ` [PATCH v4 5/8] mm/memory_hotplug: We always have a zone in find_(smallest|biggest)_section_pfn David Hildenbrand
2019-08-30 9:14 ` [PATCH v4 6/8] mm/memory_hotplug: Don't check for "all holes" in shrink_zone_span() David Hildenbrand
2019-08-30 9:14 ` [PATCH v4 7/8] mm/memory_hotplug: Drop local variables " David Hildenbrand
2019-08-30 9:14 ` [PATCH v4 8/8] mm/memory_hotplug: Cleanup __remove_pages() David Hildenbrand
2019-09-06 9:21 ` [PATCH v4 0/8] mm/memory_hotplug: Shrink zones before removing memory David Hildenbrand
2019-09-19 13:58 ` David Hildenbrand
2019-09-19 19:16 ` Andrew Morton
2019-09-20 8:16 ` David Hildenbrand
2019-09-26 12:25 ` [PATCH 1/2] mm/memunmap: Use the correct start and end pfn when removing pages from zone Aneesh Kumar K.V
2019-09-26 12:25 ` Aneesh Kumar K.V
2019-09-26 12:25 ` [PATCH 2/2] mm/memmap_init: Update variable name in memmap_init_zone Aneesh Kumar K.V
2019-09-26 12:25 ` Aneesh Kumar K.V
2019-09-26 12:56 ` David Hildenbrand
2019-09-26 12:56 ` David Hildenbrand
2019-09-26 13:38 ` Pankaj Gupta
2019-09-26 13:38 ` Pankaj Gupta
2019-09-26 12:43 ` [PATCH 1/2] mm/memunmap: Use the correct start and end pfn when removing pages from zone David Hildenbrand
2019-09-26 12:43 ` David Hildenbrand
2019-09-26 13:15 ` Aneesh Kumar K.V
2019-09-26 13:15 ` Aneesh Kumar K.V
2019-09-26 13:34 ` Pankaj Gupta
2019-09-26 13:34 ` Pankaj Gupta
2019-09-26 22:45 ` Andrew Morton
2019-09-26 22:45 ` Andrew Morton
2019-09-27 1:51 ` Aneesh Kumar K.V
2019-09-27 1:51 ` Aneesh Kumar K.V
2019-09-27 7:46 ` David Hildenbrand
2019-09-27 7:46 ` David Hildenbrand
2019-09-27 10:32 ` [PATCH] " Aneesh Kumar K.V
2019-09-27 10:32 ` Aneesh Kumar K.V
2019-09-27 10:38 ` David Hildenbrand
2019-09-27 10:38 ` David Hildenbrand
2019-09-27 10:36 ` [PATCH 1/2] " Aneesh Kumar K.V
2019-09-27 10:36 ` Aneesh Kumar K.V
2019-09-27 10:40 ` David Hildenbrand
2019-09-27 10:40 ` David Hildenbrand
2019-09-27 11:35 ` Aneesh Kumar K.V
2019-09-27 11:35 ` Aneesh Kumar K.V
2019-09-27 11:38 ` David Hildenbrand
2019-09-27 11:38 ` David Hildenbrand
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=87wodvo1yl.fsf@linux.ibm.com \
--to=aneesh.kumar@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=osalvador@suse.de \
--cc=pasha.tatashin@soleen.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.