linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Mikhail Zaslonko <zaslonko@linux.ibm.com>,
	Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>,
	Pavel Tatashin <pasha.tatashin@soleen.com>,
	schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com,
	gerald.schaefer@de.ibm.com, linux-mm@kvack.org,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/2] mm, memory_hotplug: fix uninitialized pages fallouts.
Date: Mon, 28 Jan 2019 19:41:39 +0100	[thread overview]
Message-ID: <20190128184139.GR18811@dhcp22.suse.cz> (raw)
In-Reply-To: <20190128095054.4103093dec81f1c904df7929@linux-foundation.org>

On Mon 28-01-19 09:50:54, Andrew Morton wrote:
> On Mon, 28 Jan 2019 15:45:04 +0100 Michal Hocko <mhocko@kernel.org> wrote:
> 
> > Mikhail has posted fixes for the two bugs quite some time ago [1]. I
> > have pushed back on those fixes because I believed that it is much
> > better to plug the problem at the initialization time rather than play
> > whack-a-mole all over the hotplug code and find all the places which
> > expect the full memory section to be initialized. We have ended up with
> > 2830bf6f05fb ("mm, memory_hotplug: initialize struct pages for the full
> > memory section") merged and cause a regression [2][3]. The reason is
> > that there might be memory layouts when two NUMA nodes share the same
> > memory section so the merged fix is simply incorrect.
> > 
> > In order to plug this hole we really have to be zone range aware in
> > those handlers. I have split up the original patch into two. One is
> > unchanged (patch 2) and I took a different approach for `removable'
> > crash. It would be great if Mikhail could test it still works for his
> > memory layout.
> > 
> > [1] http://lkml.kernel.org/r/20181105150401.97287-2-zaslonko@linux.ibm.com
> > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1666948
> > [3] http://lkml.kernel.org/r/20190125163938.GA20411@dhcp22.suse.cz
> 
> Any thoughts on which kernel version(s) need these patches?

My remark in 2830bf6f05fb still holds
    : This has alwways been problem AFAIU.  It just went unnoticed because we
    : have zeroed memmaps during allocation before f7f99100d8d9 ("mm: stop
    : zeroing memory during allocation in vmemmap") and so the above test
    : would simply skip these ranges as belonging to zone 0 or provided a
    : garbage.
    :
    : So I guess we do care for post f7f99100d8d9 kernels mostly and
    : therefore Fixes: f7f99100d8d9 ("mm: stop zeroing memory during
    : allocation in vmemmap")

But, please let's wait for the patch 1 to be confirmed to fix the issue.
-- 
Michal Hocko
SUSE Labs


  parent reply	other threads:[~2019-01-28 18:41 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-28 14:45 [PATCH 0/2] mm, memory_hotplug: fix uninitialized pages fallouts Michal Hocko
2019-01-28 14:45 ` Michal Hocko
2019-01-28 14:45 ` [PATCH 1/2] mm, memory_hotplug: is_mem_section_removable do not pass the end of a zone Michal Hocko
2019-01-28 14:45   ` Michal Hocko
2019-01-29  9:06   ` Oscar Salvador
2019-01-29  9:12     ` Michal Hocko
2019-01-30  7:54       ` Oscar Salvador
2019-01-28 14:45 ` [PATCH 2/2] mm, memory_hotplug: test_pages_in_a_zone do not pass the end of zone Michal Hocko
2019-01-28 14:45   ` Michal Hocko
2019-01-29  9:09   ` Oscar Salvador
2019-01-29  9:13     ` Michal Hocko
2019-01-28 17:50 ` [PATCH 0/2] mm, memory_hotplug: fix uninitialized pages fallouts Andrew Morton
2019-01-28 17:50   ` Andrew Morton
2019-01-28 18:41   ` Michal Hocko [this message]
2019-01-28 18:45     ` Michal Hocko
2019-01-29 13:14 ` Gerald Schaefer
2019-01-29 13:49   ` Michal Hocko
2019-01-29 14:08     ` Gerald Schaefer
2019-01-29 17:38     ` Mikhail Gavrilov
2019-01-29 20:24       ` Michal Hocko
2019-01-29 20:56         ` Mikhail Gavrilov

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=20190128184139.GR18811@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=gerald.schaefer@de.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mikhail.v.gavrilov@gmail.com \
    --cc=pasha.tatashin@soleen.com \
    --cc=schwidefsky@de.ibm.com \
    --cc=zaslonko@linux.ibm.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;
as well as URLs for NNTP newsgroup(s).