All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerald Schaefer <gerald.schaefer@de.ibm.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Mikhail Zaslonko <zaslonko@linux.ibm.com>,
	Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Pavel Tatashin <pasha.tatashin@soleen.com>,
	schwidefsky@de.ibm.com, heiko.carstens@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: Tue, 29 Jan 2019 14:14:47 +0100	[thread overview]
Message-ID: <20190129141447.34aa9d0c@thinkpad> (raw)
In-Reply-To: <20190128144506.15603-1-mhocko@kernel.org>

On Mon, 28 Jan 2019 15:45:04 +0100
Michal Hocko <mhocko@kernel.org> wrote:

> Hi,
> 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

I verified that both patches fix the issues we had with valid_zones
(with mem=2050M) and removable (with mem=3075M).

However, the call trace in the description of your patch 1 is wrong.
You basically have the same call trace for test_pages_in_a_zone in
both patches. The "removable" patch should have the call trace for
is_mem_section_removable from Mikhails original patches:

 CONFIG_DEBUG_VM_PGFLAGS=y
 kernel parameter mem=3075M
 --------------------------
 page:000003d08300c000 is uninitialized and poisoned
 page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p))
 Call Trace:
 ([<000000000038596c>] is_mem_section_removable+0xb4/0x190)
  [<00000000008f12fa>] show_mem_removable+0x9a/0xd8
  [<00000000008cf9c4>] dev_attr_show+0x34/0x70
  [<0000000000463ad0>] sysfs_kf_seq_show+0xc8/0x148
  [<00000000003e4194>] seq_read+0x204/0x480
  [<00000000003b53ea>] __vfs_read+0x32/0x178
  [<00000000003b55b2>] vfs_read+0x82/0x138
  [<00000000003b5be2>] ksys_read+0x5a/0xb0
  [<0000000000b86ba0>] system_call+0xdc/0x2d8
 Last Breaking-Event-Address:
  [<000000000038596c>] is_mem_section_removable+0xb4/0x190
 Kernel panic - not syncing: Fatal exception: panic_on_oops


  parent reply	other threads:[~2019-01-29 13:15 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
2019-01-29 13:14 ` Gerald Schaefer [this message]
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=20190129141447.34aa9d0c@thinkpad \
    --to=gerald.schaefer@de.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.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.