From: Michal Hocko <mhocko@kernel.org>
To: David Hildenbrand <david@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH v2 2/2] mm/memory-failure.c: Don't access uninitialized memmaps in memory_failure()
Date: Thu, 10 Oct 2019 09:35:26 +0200 [thread overview]
Message-ID: <20191010073526.GC18412@dhcp22.suse.cz> (raw)
In-Reply-To: <5a626821-77e9-e26b-c2ee-219670283bf0@redhat.com>
On Thu 10-10-19 09:27:32, David Hildenbrand wrote:
> On 09.10.19 16:43, Michal Hocko wrote:
> > On Wed 09-10-19 16:24:35, David Hildenbrand wrote:
> >> We should check for pfn_to_online_page() to not access uninitialized
> >> memmaps. Reshuffle the code so we don't have to duplicate the error
> >> message.
> >>
> >> Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> >> Cc: Andrew Morton <akpm@linux-foundation.org>
> >> Cc: Michal Hocko <mhocko@kernel.org>
> >> Signed-off-by: David Hildenbrand <david@redhat.com>
> >> ---
> >> mm/memory-failure.c | 14 ++++++++------
> >> 1 file changed, 8 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> >> index 7ef849da8278..e866e6e5660b 100644
> >> --- a/mm/memory-failure.c
> >> +++ b/mm/memory-failure.c
> >> @@ -1253,17 +1253,19 @@ int memory_failure(unsigned long pfn, int flags)
> >> if (!sysctl_memory_failure_recovery)
> >> panic("Memory failure on page %lx", pfn);
> >>
> >> - if (!pfn_valid(pfn)) {
> >> + p = pfn_to_online_page(pfn);
> >> + if (!p) {
> >> + if (pfn_valid(pfn)) {
> >> + pgmap = get_dev_pagemap(pfn, NULL);
> >> + if (pgmap)
> >> + return memory_failure_dev_pagemap(pfn, flags,
> >> + pgmap);
> >> + }
> >> pr_err("Memory failure: %#lx: memory outside kernel control\n",
> >> pfn);
> >> return -ENXIO;
> >
> > Don't we need that earlier at hwpoison_inject level?
> >
>
> Theoretically yes, this is another instance. But pfn_to_online_page(pfn)
> alone would not be sufficient as discussed. We would, again, have to
> special-case ZONE_DEVICE via things like get_dev_pagemap() ...
>
> But mm/hwpoison-inject.c:hwpoison_inject() is a pure debug feature either way:
>
> /*
> * Note that the below poison/unpoison interfaces do not involve
> * hardware status change, hence do not require hardware support.
> * They are mainly for testing hwpoison in software level.
> */
>
> So it's not that bad compared to memory_failure() called from real HW or
> drivers/base/memory.c:soft_offline_page_store()/hard_offline_page_store()
Yes, this is just a toy. And yes we need to handle zone device pages
here because a) people likely want to test MCE behavior even on these
pages and b) HW can really trigger MCEs there as well. I was just
pointing that the patch is likely incomplete.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2019-10-10 7:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-09 14:24 [PATCH v2 0/2] mm: Don't access uninitialized memmaps in PFN walkers David Hildenbrand
2019-10-09 14:24 ` [PATCH v2 1/2] mm: Don't access uninitialized memmaps in fs/proc/page.c David Hildenbrand
2019-10-09 14:41 ` Michal Hocko
2019-10-14 8:44 ` David Hildenbrand
2019-10-09 14:24 ` [PATCH v2 2/2] mm/memory-failure.c: Don't access uninitialized memmaps in memory_failure() David Hildenbrand
2019-10-09 14:43 ` Michal Hocko
2019-10-10 7:27 ` David Hildenbrand
2019-10-10 7:35 ` Michal Hocko [this message]
2019-10-10 7:52 ` David Hildenbrand
2019-10-10 7:58 ` David Hildenbrand
2019-10-11 6:02 ` Naoya Horiguchi
2019-10-11 10:13 ` David Hildenbrand
2019-10-14 13:36 ` Michal Hocko
2019-10-15 14:23 ` Oscar Salvador
2019-10-10 0:26 ` Naoya Horiguchi
2019-10-10 7:17 ` David Hildenbrand
2019-10-11 6:50 ` Naoya Horiguchi
2019-10-19 2:05 ` Andrew Morton
2019-10-21 9:44 ` David Hildenbrand
2019-10-14 8:41 ` 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=20191010073526.GC18412@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=n-horiguchi@ah.jp.nec.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