All of lore.kernel.org
 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:45:28 +0100	[thread overview]
Message-ID: <20190128184528.GU18811@dhcp22.suse.cz> (raw)
In-Reply-To: <20190128184139.GR18811@dhcp22.suse.cz>

On Mon 28-01-19 19:41:39, Michal Hocko wrote:
> 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.

Also the revert [1] should be applied first. I thought Linus would pick
it up but he hasn't done so yet.

[1] http://lkml.kernel.org/r/20190125181549.GE20411@dhcp22.suse.cz
-- 
Michal Hocko
SUSE Labs

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

Thread overview: 23+ 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
2019-01-28 18:45     ` Michal Hocko [this message]
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 17:38       ` Mikhail Gavrilov
2019-01-29 20:24       ` Michal Hocko
2019-01-29 20:56         ` Mikhail Gavrilov
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=20190128184528.GU18811@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 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.