From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 51F73C47404 for ; Fri, 11 Oct 2019 06:15:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0D94A21A4A for ; Fri, 11 Oct 2019 06:15:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0D94A21A4A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ah.jp.nec.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7A6BD8E0005; Fri, 11 Oct 2019 02:15:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7573E8E0003; Fri, 11 Oct 2019 02:15:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 66CB18E0005; Fri, 11 Oct 2019 02:15:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0076.hostedemail.com [216.40.44.76]) by kanga.kvack.org (Postfix) with ESMTP id 461E48E0003 for ; Fri, 11 Oct 2019 02:15:43 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id C37E182437C9 for ; Fri, 11 Oct 2019 06:15:42 +0000 (UTC) X-FDA: 76030492524.26.steam05_4ee3abfd83e1e X-HE-Tag: steam05_4ee3abfd83e1e X-Filterd-Recvd-Size: 7024 Received: from tyo162.gate.nec.co.jp (tyo162.gate.nec.co.jp [114.179.232.162]) by imf10.hostedemail.com (Postfix) with ESMTP for ; Fri, 11 Oct 2019 06:15:41 +0000 (UTC) Received: from mailgate01.nec.co.jp ([114.179.233.122]) by tyo162.gate.nec.co.jp (8.15.1/8.15.1) with ESMTPS id x9B6FatW020534 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 11 Oct 2019 15:15:36 +0900 Received: from mailsv01.nec.co.jp (mailgate-v.nec.co.jp [10.204.236.94]) by mailgate01.nec.co.jp (8.15.1/8.15.1) with ESMTP id x9B6FZuR002915; Fri, 11 Oct 2019 15:15:36 +0900 Received: from mail02.kamome.nec.co.jp (mail02.kamome.nec.co.jp [10.25.43.5]) by mailsv01.nec.co.jp (8.15.1/8.15.1) with ESMTP id x9B6E396014848; Fri, 11 Oct 2019 15:15:35 +0900 Received: from bpxc99gp.gisp.nec.co.jp ([10.38.151.147] [10.38.151.147]) by mail02.kamome.nec.co.jp with ESMTP id BT-MMP-9394841; Fri, 11 Oct 2019 15:02:51 +0900 Received: from BPXM23GP.gisp.nec.co.jp ([10.38.151.215]) by BPXC19GP.gisp.nec.co.jp ([10.38.151.147]) with mapi id 14.03.0439.000; Fri, 11 Oct 2019 15:02:50 +0900 From: Naoya Horiguchi To: David Hildenbrand CC: Michal Hocko , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , Andrew Morton Subject: Re: [PATCH v2 2/2] mm/memory-failure.c: Don't access uninitialized memmaps in memory_failure() Thread-Topic: [PATCH v2 2/2] mm/memory-failure.c: Don't access uninitialized memmaps in memory_failure() Thread-Index: AQHVfq1QC/9/3IlYuEK91tWnhgAEnKdRy5KAgAEYjwCAAAI1AIAABLgAgAABxQCAAXH3gA== Date: Fri, 11 Oct 2019 06:02:49 +0000 Message-ID: <20191011060249.GA30500@hori.linux.bs1.fc.nec.co.jp> References: <20191009142435.3975-1-david@redhat.com> <20191009142435.3975-3-david@redhat.com> <20191009144323.GH6681@dhcp22.suse.cz> <5a626821-77e9-e26b-c2ee-219670283bf0@redhat.com> <20191010073526.GC18412@dhcp22.suse.cz> <18383432-c74a-9ce5-a3c6-1e57d54cb629@redhat.com> <52e81b85-c460-5b99-a297-e065caab3a16@redhat.com> In-Reply-To: <52e81b85-c460-5b99-a297-e065caab3a16@redhat.com> Accept-Language: en-US, ja-JP Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.34.125.96] Content-Type: text/plain; charset="iso-2022-jp" Content-ID: <89CA1456C580664C8DA0362F03F6C601@gisp.nec.co.jp> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Oct 10, 2019 at 09:58:40AM +0200, David Hildenbrand wrote: > On 10.10.19 09:52, David Hildenbrand wrote: > > On 10.10.19 09:35, Michal Hocko wrote: > >> 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 uninitialize= d > >>>>> memmaps. Reshuffle the code so we don't have to duplicate the error > >>>>> message. > >>>>> > >>>>> Cc: Naoya Horiguchi > >>>>> Cc: Andrew Morton > >>>>> Cc: Michal Hocko > >>>>> Signed-off-by: David Hildenbrand > >>>>> --- > >>>>> 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 f= lags) > >>>>> if (!sysctl_memory_failure_recovery) > >>>>> panic("Memory failure on page %lx", pfn); > >>>>> =20 > >>>>> - if (!pfn_valid(pfn)) { > >>>>> + p =3D pfn_to_online_page(pfn); > >>>>> + if (!p) { > >>>>> + if (pfn_valid(pfn)) { > >>>>> + pgmap =3D 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(p= fn) > >>> 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 ei= ther 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_sto= re() > >> > >> 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. > >> > >=20 > > I rather think this deserves a separate patch as it is a separate > > interface :) > >=20 > > I do wonder why hwpoison_inject() has to perform so much extra work > > compared to other memory_failure() users. This smells like legacy > > leftovers to me, but I might be wrong. The interface is fairly old, > > though. Does anybody know why we need this magic? I can spot quite some > > duplicate checks/things getting performed. It concerns me too, this *is* an old legacy code. I guess it was left as-is because no one complained about it. That's not good, so I'll do some clean= up. > >=20 > > Naiive me would just make the interface perform the same as > > hard_offline_page_store(). But most probably I am not getting the real > > purpose of both different interfaces. Maybe for historical reason, we have these slightly different interfaces: - corrupt-pfn - purely for debugging purpose - paired with unpoison-pfn - used by in-kernel tool tools/vm/page-types.c - hard_offline_page - paired with soft_offline_page - used by other userspace tools like mcelog But these don't explain why implemented differently, so I think that both should be written in the same manner. > >=20 > > HWPOISON_INJECT is only selected for DEBUG_KERNEL, so I would have > > guessed that fixing this is not urgent. > >=20 > > BTW: mm/memory-failure.c:soft_offline_page() also looks wrong and needs > > fixing to make sure we access initialized memmaps. > >=20 >=20 > To be more precise, soft_offline_page_store() needs a > pfn_to_online_page() check. Will send a patch. Thanks for finding this. - Naoya Horiguchi=